Institute of Parallel and Distributed Systems University of Stuttgart Universitätsstraße 38 D–70569 Stuttgart Masterthesis Application Integration and Team Collaboration for Process Optimization in Intralogistics Sabri Bektas Course of Study: Informatik Examiner: Prof. Dr. Benjamin Uekermann Supervisor: Dipl.-Ing. Thomas Rassmann Commenced: January 26, 2023 Completed: July 26, 2023 Abstract This work focuses on the potential benefits of integrating software applications and promoting team collaboration to enhance intralogistic processes at Robert Bosch GmbH in Feuerbach. The current study is a synthesis of a comprehensive review of pertinent literature and the practical application of an architectural framework. This research addresses the gap in literature, which lacks comprehensive guidelines for choosing software architecture approaches aligned with non-functional requirements. The objectives are to determine the necessary functionalities for an integrated solution, evaluate existing solutions and technical models, design a target architecture and provide practical guidelines for implementation. The key research question revolves around how already existing solutions can be integrated to enhance intralogistics processes. To achieve these objectives, a comprehensive literature review is conducted to identify suitable software architecture approaches. The study evaluates various methodologies, considering non-functional requirements, culminating in an architecture ranking matrix. Additionally, interviews with project teams and analysis of user stories guide architectural decisions. The research emphasizes the microservices architecture as the selected approach for seamless integration. The message of this research is that the microservices architecture offers a scalable, modular, and efficient solution for optimizing intralogistic processes. By integrating existing software solutions and fostering effective teamwork, organizations can achieve enhanced sustainability and customer experience. This research contributes valuable insights and practical recommendations for leveraging existing solutions to develop comprehensive and efficient intralogistics application systems. The proposed architecture serves as a template and guideline for the Virtual Development Team at Robert Bosch GmbH, facilitating the realization of an optimized and sustainable target system for intralogistics. 3 Contents 1 Introduction 13 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.2 Scope of this Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2 Literature Review 17 2.1 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2 Software Architecture Design Approaches . . . . . . . . . . . . . . . . . . . . . . 19 2.3 Software Architecture Design Approaches Comparison . . . . . . . . . . . . . . . 31 2.4 Software Architecture Design Approaches Ranking based on Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3 Integration Projects Overview 47 3.1 Business Understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.2 Stakeholder Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.3 System Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4 User Stories 57 4.1 User Stories Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . 57 4.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5 Architecture Modelling 65 5.1 Architecture Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.2 Building Block View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.3 Component View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.4 Runtime View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.5 Deployment View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6 Conclusion 79 Bibliography 81 A Project Team Interviews 87 A.1 ShipSmart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 A.2 Optical Inspection System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 A.3 Camera Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 A.4 AutoID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 A.5 ShipQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5 B Architecture Decisions 97 B.1 Camera Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 B.2 Customer Requirements Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 99 B.3 Customer Requirements Visualization (Packer User Interface (UI)) . . . . . . . . 101 B.4 Customer Requirements Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 B.5 Packaging Validation Hardware Setup . . . . . . . . . . . . . . . . . . . . . . . . 105 B.6 Packaging Validation Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 B.7 Packaging Validation Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 B.8 Delivery Model Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 6 List of Figures 2.1 Key Word Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1 User Interaction of Target System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.1 Use Case Coverage Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.1 OIS and Camera Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.2 Building Block View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.3 Component View - Shipment Validation Overall . . . . . . . . . . . . . . . . . . . 72 5.4 Component View - Shipment Validation - Image Preprocessing Service . . . . . . 73 5.5 Component View - Shipment Validation - Detection Service . . . . . . . . . . . . 74 5.6 Component View - Shipment Validation - Validation Service . . . . . . . . . . . . 74 5.7 Runtime View - Shipment Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.8 Deployment View - Shipment Validation . . . . . . . . . . . . . . . . . . . . . . . . 77 7 List of Tables 2.1 Architecture-Centric Design - Advantages & Disadvantages . . . . . . . . . . . . . 21 2.2 Microservices Architecture - Advantages & Disadvantages . . . . . . . . . . . . . 22 2.3 Cloud-Native Architecture - Advantages & Disadvantages . . . . . . . . . . . . . . 24 2.4 Waterfall Software Development - Advantages & Disadvantages . . . . . . . . . . 25 2.5 Domain-Driven Design - Advantages & Disadvantages . . . . . . . . . . . . . . . 26 2.6 Service-Oriented Architecture - Advantages & Disadvantages . . . . . . . . . . . . 27 2.7 Event-Driven Architecture - Advantages & Disadvantages . . . . . . . . . . . . . . 28 2.8 Model-Driven Architecture - Advantages & Disadvantages . . . . . . . . . . . . . 29 2.9 Reactive Architecture - Advantages & Disadvantages . . . . . . . . . . . . . . . . 31 2.10 Architectures - Advantages & Disadvantages & Key Features . . . . . . . . . . . . 32 2.11 Architecture Evaluation Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.12 Architecture Ranking Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.1 Project Comparison Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.2 Stakeholder Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.3 Actor description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.1 Requirements of User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.2 Non-Functional-Requirements Evaluation . . . . . . . . . . . . . . . . . . . . . . . 64 5.1 Architecture ranking table updated based on questionnaires . . . . . . . . . . . . . 65 5.2 Architecture Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 B.1 Camera Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 B.2 Customer Requirements Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 B.3 Customer Requirements Visualization (Packer UI) . . . . . . . . . . . . . . . . . . 103 B.4 Customer Requirements Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 B.5 Packaging Validation Hardware Setup . . . . . . . . . . . . . . . . . . . . . . . . . 107 B.6 Packaging Validation Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 B.7 Packaging Validation Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 B.8 Delivery Model Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 9 Acronyms AD Architecture Decision. 66 AI Artificial intelligence. 13 AKS Azure Kubernetes Service. 76 API Application Programming Interface. 18 B2B Business-to-Business. 49 B2C Business-to-Consumer. 49 BOM Bill of Materials. 90 C&C Component-and-connector. 17 CA Camera Area. 59 CI/CD Continuous Integration/Continuous Deployment. 23 CNA Cloud-Native Architecture. 20 CQRS Command Query Responsibility Segregation. 30 DDD Domain-Driven Design. 20 DevOps Development and Operations. 24 EDA Event-Driven Architecture. 20 HTTP Hypertext Transfer Protocol. 27 HU Handling Unit. 89 IdM Identity Management. 90 ISO International Organization for Standardization. 87 JSON JavaScript Object Notation. 37 KPI Key Performance Indicators. 50 LDAP Lightweight Directory Access Protocol. 90 MDA Model-Driven Architecture. 20 OCR Optical Character Recognition. 73 OIS Optical Inspection System. 59 OS Operating System. 76 11 Acronyms PIM Platform-Independent Model. 29 PoC Proof of Concept. 87 PSM Platform-Specific Model. 29 QA Quality Attribute. 18 QMH Queued Message Handler. 88 REST Representational State Transfer. 22 RFID Radio-Frequency Identification. 72 SaaS Software-as-a-Service. 113 SFTP Secure File Transfer Protocol. 88 SOA Service-Oriented Architecture. 20 SOAP Simple Object Access Protocol. 27 UI User Interface. 6 UML Unified Modeling Language. 15 UX User Experience. 48 VDT Virtual Development Team. 13 XML Extensible Markup Language. 37 YOLO You Only Look Once. 89 12 1 Introduction 1.1 Background The fourth industrial revolution introduced innovative technologies that provide new opportunities for improving production and logistics systems. Intralogistics, which entails the management of resources such as materials and data within a warehouse or distribution centre, is essential for guaranteeing efficient supply chain operations. For these facilities to meet customer demands and maintain profitability, it is essential that they efficiently handle products. However, optimising intralogistics processes is a difficult task that requires the coordination of multiple teams and the integration of numerous technologies. Companies can optimise their intralogistics processes by employing the appropriate software applications and nurturing effective teamwork. This study examines the potential benefits of application integration and team collaboration to enhance intralogistics processes within the context of research conducted at Robert Bosch GmbH in Feuerbach. The research focuses on integrating applications, enhancing sustainability and enhancing the consumer experience. The automated identification of products within intralogistics processes is a challenge. In the production route of Bosch, the automation of such processes is necessary. The benefits of automation include the rapid categorization of goods in warehouses, which reduces barriers in the goods receiving and disposal processes. Another advantage is the interface with other functions that use this automation data for further goods administration. Artificial intelligence (AI) is a crucial component of these automations, especially in goods recognition, which involves the analysis of image data acquired from a camera system at a warehouse’s entrance. The Bosch Corporation has a global presence, with departments and warehouses located in various regions. To improve their processes, some of these stations have developed an intralogistics system for automated product recognition. Currently, three geographically dispersed development teams in Germany, Portugal and the Czech Republic are autonomously working on similar solutions. These solutions include functionalities such as label recognition that are comparable. The proposed concept of a Virtual Development Team (VDT) seeks to unify these disparate teams around a central hub. This collaborative approach aims to promote knowledge exchange and mutual support, resulting in solutions that are more effective, optimised and deployed more quickly. In addition, this strategy endeavours to avoid duplicative solution development. 13 1 Introduction 1.2 Scope of this Research Software architecture design is crucial to software projects. According to Chen et al. (2022), it serves as a roadmap for the development team to follow while they create a system that can achieve the project’s objectives [Cha20]. By outlining the framework and building blocks of the system, software architecture design facilitates efficient collaboration amongst developers. The success of a software project might be jeopardized by poor architectural planning. Bishung et al. (2019) indicated that it might lead to technical debt, which would increase the difficulty and expense of system maintenance [BKO+19]. System performance, scalability and dependability might be negatively impacted as a result, leading to unhappy customers and financial losses for businesses. Software projects benefit from effective architectural designs. As a consequence, it has the potential to provide a durable, scalable and low-maintenance system that boosts customer satisfaction and organizational success. Sievi-Korte et al. (2019) argued that a flexible software architecture might also aid in meeting evolving company needs [SRB19]. It is the reason that software architecture design aids programmers in making a product that accomplishes the desired goals. This work will investigate and propose a report for integrating and combining existing applications. The main research question is: How can already existing solutions be integrated or combined? To achieve this the study seeks to accomplish the following specific objectives: • Determine the necessary functionalities for an integrated solution. • Evaluate a variety of extant solutions and technical models to determine which ones best meet the specified needs. • Create a target architecture for combining and integrating the chosen solutions. • Provide guidelines and recommendations for implementing the proposed framework in real-world scenarios. By addressing these objectives, the study intends to contribute to the field of software integration by providing insights and practical recommendations for leveraging existing initiatives to develop more comprehensive and efficient application systems. During the course of my thesis, I received valuable support and guidance from my colleagues at Bosch, who possess extensive expertise in the field of software architecture design. Their mentorship proved instrumental in guiding me through the entire process. However, the specific area of the shipment validation became the focal point of my individual efforts. I crafted the architectural draft for this essential component. Subsequently, I presented and proposed the drafted architecture to the VDT. 14 1.3 Structure 1.3 Structure The work is structured as follows: Chapter 2 – Literature Review: The literature review is presented in the second chapter, wherein an analysis of contemporary software architecture approaches is conducted. Furthermore, a ranking matrix is provided to facilitate the process of architecture selection. Chapter 3 – Integration Projects Overview: This chapter showcases the various source projects that require integration, alongside the presentation of the user interaction within the target system. Chapter 4 – User Stories: The fourth chapter focuses on the user stories that outline the functional and non-functional requirements of the target system. These stories are prioritized based on their importance. Chapter 5 – Architecture Modelling: This chapter provides an in-depth analysis of the architec- ture pertaining to the shipment validation component of the target system. It elucidates the Component View, Runtime View and Deployment View through the utilization of Unified Modeling Language (UML) notation. Chapter 6 – Conclusion: In the last chapter, the results of the work are summarized and points of reference are presented. 15 2 Literature Review Software architecture designs refer to the overall structure and organization of software systems. The purpose of software architecture is to provide a high-level overview of how the system is designed, how its components interact with each other and how it fulfils its functional and non-functional requirements. The fundamental principle of software architecture is that every software system is designed and implemented to achieve an organization’s business goals. Project teams can gain valuable insights into the benefits and drawbacks of various design methodologies by conducting a comprehensive analysis of recent research and empirical studies. In addition, a literature review can provide a greater understanding of the current state of industry research and practice. A collection of components joined by a relationship is referred to as a structure. These structures cover the individual software parts, their interactions and the characteristics of each. Numerous structures are used in the construction of software systems and none of those structures can be regarded as “the architecture“. These structures can be classified into three primary categories, each of which provides a valuable framework for understanding the architecture [Len12] [Kra15]: • Component-and-connector (C&C) structures • Module structures • Allocation structure C&C structures are concerned with the interactions between elements at runtime to accomplish the functions of a system. C&C structures describe how a system is organized as a collection of components, which represent the main units of computation. Connectors, on the other hand, act as communication channels between components. Components can take various forms, including services, peers, clients, servers and filters. Meanwhile, connectors facilitate communication between components using methods like call-return, process synchronization operators and pipes. [Tov19a] [ARI15] Module structures are used to divide systems into implementation units, known as modules, which indicate how a system is constructed or procured. Modules have specific computational tasks and are used as a basis for work assignments for programming teams. In a module structure, the system’s elements are modules of some kind, such as classes, packages, layers or other functional divisions that are units of implementation. The focus of module structures is on static considerations of the system, with less emphasis on how the software appears at runtime. Therefore, modules represent a static way of analysing the system, with each module being assigned to a functional area of responsibility. [NPHK15] Allocation structures define how software structures are mapped to non-software structures within a system, such as a system’s organization, development, testing and execution environments [Len12]. 17 2 Literature Review All of the software architecture design techniques evaluated in the aforementioned literature review provide full support for these three frameworks. The following literature is recommended for obtaining additional information on the three structures and their associated patterns: • L. Bass, P. Clements and R. Kazman, “Software Architecture in Practice (3rd Edition)”, Architecture, 2012 [Len12] • Mark Richards, “Software Architecture Patterns”, O’Reilly Media, 2015 [Ric15] This evaluation will employ the non-functional requirements described in the subsequent section. They are also referred to as Quality Attributes (QA) and are used to evaluate system architectures during development and operation. Consequently, this evaluation employs these characteristics to guide decision-making during the design phase of software architecture. The prevalent modern approaches to software architecture are then described and compared. Next, a subjective ranking value is assigned to the architecture design approaches, which may differ depending on the specific implementation of the approach. Finally, a ranking table will be created and used in the succeeding thesis to select an approach to software architecture. 2.1 Non-Functional Requirements A QA is a measurable or testable aspect of a system that indicates how effectively the system meets the needs of its stakeholders beyond the system’s core function. A quality characteristic can be thought of as quantifying a product’s “utility“ along some dimension of importance to a stakeholder. • Availability: A Software’s ability to be active and prepared to perform its function whenever you need it, is referred to as availability. By introducing the idea of recovery, availability expands upon the idea of reliability by stating that when a system malfunctions, it fixes itself. • Scalability: Is used to describe the capacity of a system to accommodate growing numbers of users or data records without degrading performance. Horizontal and vertical scaling, as well as load balancing and clustering, should all be considered while designing a scalable architecture. • Deployability: This is a property that describes how quickly and easily a piece of software can be made available for use on a wide range of hardware and operating systems. Dependencies should be kept to a minimum, configuration efforts should be kept to a minimum and deployment consistency should be maintained across environments if the architecture is to be considered deployable. • Integrability: The capacity of software architecture to integrate without friction with other systems and applications is referred to as Integrability. For an architecture to be easily integrated with other systems, it must be built to accommodate a wide range of integration patterns, data formats and protocols and have well-defined Application Programming Interfaces (API). 18 2.2 Software Architecture Design Approaches • Performance: Performance, in the context of software architecture, pertains to the capability of the system to operate with effectiveness and efficiency across diverse contexts and under varying workloads. A performant architecture is one that achieves the best possible results in terms of throughput, scalability and resource usage, with the least possible latency and reaction time. • Testability: The capacity to test and verify the accuracy, resilience and performance of a software design is known as its testability. A testable architecture is one that can facilitate automated testing, has comprehensive documentation and provides accurate error reporting. • Ease of Development: The simplicity and efficiency with which a software architecture may be created, maintained and updated by its creators is what this quality metric is measuring. Rapid prototyping, modularity and the obvious separation of responsibilities are all features that should be supported by an easily-developable architecture. • Modifiability: Software architecture modifiability is the trait of being easily and effectively updated, expanded and changed. • Usability: Usability is a quality characteristic that describes how easily, successfully and satisfactorily users may use a software system to accomplish their objectives. It includes features like user happiness, learnability, usability and fault tolerance. A software system that is easy to use can increase user productivity, cut support expenses and training time and increase user acceptance. [Len12] 2.2 Software Architecture Design Approaches In the literature review, techniques based on the most prominent search terms for software architecture are considered. The following search terms were used: “software development“ OR “software engineering“ “modern software architecture“ OR “modern software designing“ “software architecture patterns“ OR “software design patterns“ AND “software architecture“ OR “architectural design“ Google Scholar, IEEE, ACM, ResearchGate and Science Direct were utilised to locate articles and publications. If the abstracts were considered suitable, papers whose topics corresponded to the interests of the review were included. Following the selection of relevant literature, the abstracts were combined to produce a word diagram (Figure 2.1), with the magnitude of each word corresponding to its frequency in the list of keywords. 19 2 Literature Review 5/4/23, 8:11 PM TagCrowd: create your own word cloud from any text https://tagcrowd.com 1/1 services applications components event microservices business domain method process reactive scalability flexibility implementation management mda module needed soa testingused advantages allows cloud increased modularity performance waterfall allocation approaches cloud-native connector ddd deployment difficult eda event-driven independently resources architecture-centric argued consistency create deployed language responsiveness stated step tasks team technologies Figure 2.1: Key Word Frequency On the basis of the frequency of the associated terms, the following strategies were investigated: • Architecture-Centric Design • Microservices Architecture • Cloud-Native Architecture (CNA) • Waterfall Software Development • Domain-Driven Design (DDD) • Service-Oriented Architecture (SOA) • Event-Driven Architecture (EDA) • Model-Driven Architecture (MDA) • Reactive Architecture The explanations that follow will first describe the specific approach, followed by a description of the phases involved, then list the advantages and disadvantages and lastly describe how the fundamental structures are integrated. 20 2.2 Software Architecture Design Approaches 2.2.1 Architecture-Centric Design Architecture-centric design is the process of designing software with an emphasis on architecture over implementation. This method, according to Siek (2011), ensures that software architecture is adhered to during implementation [Sie11]. The following are typical phases of an architecture-centric design: 1. The planning stage focuses on what the system requires and how it should be constructed. 2. The design stage plans the system’s architecture [MOTG17]. 3. The authentication and confirmation phase includes analysing and evaluating the architecture to ensure that it is of adequate quality and meets all system requirements [BKO+19]. 4. The implementation phase entails the actual execution of the system architecture designed in previous phases. Advantages Disadvantages Encourages early consideration of system ar- chitecture [FYX20] Can lead to over-engineering or premature optimization [DL01] Ability to develop and adapt to new circum- stances by a well-architected system can keep up with the evolving needs of a business [SRB19] May not accommodate changing requirements or evolving technologies as easily as other approaches [Dev17] Can facilitate the creation of more robust and scalable systems [CSW21] May require significant up-front investment in time and resources [Jai19] May be easier to test and debug due to clearly defined and modular architecture [RJ06] Can limit creativity and innovation in the de- velopment process [Cha20] Can help identify potential risks and issues before they become major problems [DL01] May not be as adaptable to certain types of projects or team structures [Cha20] Table 2.1: Architecture-Centric Design - Advantages & Disadvantages The Architecture-Centric Design methodology focuses on elucidating the system’s components and connections. It emphasises breaking down complex systems into smaller, more manageable components, each of which performs a narrowly defined set of duties and connecting those components via suitable communication channels. The strategy recommends a modular architecture that simplifies maintenance and adaptation, as well as a clear separation of concerns [XYBZ19] [GPNV02]]. This method also takes allocation structures into consideration, as it attempts to assign system components to actual hardware resources [Bos04]. The end result of this method is an efficient system with well-defined interfaces between its components and judicious use of available resources. 21 2 Literature Review 2.2.2 Microservices Architecture The term “microservices architecture“ alludes to a type of software architecture in which an application is divided into several small, independent components. Each service serves a distinct purpose and may interact with other services via APIs that are well-defined. [AC22] In recent years, microservices architecture has gained popularity due to its capacity to facilitate rapid software development and deployment, as well as the straightforward scalability of individual services. The process of implementing a microservices architecture includes isolating the various services responsible for the application’s essential operations and features. [BQT22] Microservice architecture prioritizes modularity, concern separation and scalability. It involves deploying services independently using appropriate technology and resources. Kubernetes and Docker Swarm can be used for service management and communication between services is enabled through gateways or meshes. [AAE16] The following are typical phases of a microservice architecture design [BQT22]: 1. Microservice architecture involves analyzing a monolithic application, identifying its compo- nents and breaking them down into smaller, independent services. 2. Clear boundaries for each microservice are defined, determining their responsibilities and communication protocols. 3. Effective communication mechanisms are designed using Representational State Transfer (REST), APIs or message queues. 4. Deployment and scalability aspects are also crucial, with a robust infrastructure designed to handle high traffic loads and scale up or down based on demand. 5. Monitoring and management of microservices are vital for smooth operation, with effective logging, error handling and performance monitoring techniques helping identify issues and optimize system performance. Advantages Disadvantages Can be scaled independently, allowing for greater scalability and flexibility [WLS22] Can add complexity, requiring careful design and management [OHM+15] Can be designed to be resilient, with the ability to isolate and recover from failures [SAAA23] With many services, there is a greater need for monitoring, management and coordination [MMd18] Can be developed using different technologies, allowing for greater flexibility and innovation [WLS22] May require additional infrastructure and tool- ing, which can increase costs [RMM16] Can enable greater autonomy for development teams, allowing for faster decision-making and innovation [AAE16] Integrating multiple microservices can be com- plex, requiring careful planning and manage- ment [AAE16] Susceptible to network delays and disruptions [AAE16] Table 2.2: Microservices Architecture - Advantages & Disadvantages 22 2.2 Software Architecture Design Approaches The microservices architecture design concepts provide support for C&C, Module and Allocation Structures. With this architecture, each microservice operates independently but can exchange data with other microservices via well-defined communication channels [Len12] [Kra15]. The modularity of microservices empowers developers to create a loosely coupled architecture wherein each module assumes responsibility for a singular task and can be autonomously updated, deployed, and scaled. This attribute of microservices allows for effective allocation of real or virtual resources in response to demand. 2.2.3 Cloud-Native Architecture The term CNA alludes to a style of construction that has been optimised for cloud-based computer systems. It is the next stage beyond “conventional“ on-premise software development, in which apps are developed with cloud compatibility in mind. Using CNA, developers construct and release software applications utilising cloud-native tools such as containerization, microservices and serverless computing [Lin17]. This technique decreases development and deployment durations while enhancing scalability, robustness and portability[BHJ16]. The following are typical phases of a cloud-native design [KEP18]: 1. Design and Planning is the initial phase of cloud-native application development, gathering requirements and defining the architecture. This includes defining microservices, selecting appropriate cloud technologies, and planning the development process. 2. Development and Coding involves software development, implementing features, integrating with external services, and ensuring the code is cloud-native and scalable. 3. Containerization and Packaging involves packaging the developed software into containers, enabling consistent application running across various environments. 4. Continuous Integration/Continuous Deployment (CI/CD) practices are essential in cloud- native development, automating code changes into a shared repository and testing it. 5. Orchestration and Management is the phase where a container orchestration platform like Kubernetes is used to manage and automate container deployment, scaling, and monitoring, ensuring the application is highly available, scalable, and resilient. 23 2 Literature Review Advantages Disadvantages Scalability: Easy to scale horizontally and vertically [AP16] Complex architecture, may require more exper- tise[KEP18] Resilience: High availability and fault toler- ance [R G22b] High cost, requires significant investment in infrastructure [Pet17] Agility: Fast and easy to deploy changes [AP16] Requires a mature Development and Opera- tions (DevOps) culture and toolset [KEP18] Portability: Can be deployed across different cloud platforms [DL22] Complexities in managing distributed data and state [Pet17] Efficiency: Optimized for cloud resources [Clo20] Increased network traffic and latency [Lin17] Entails risk of vendor lock-in, in which appli- cations are restricted to using a single cloud service or set of technologies [BHJ16] Table 2.3: Cloud-Native Architecture - Advantages & Disadvantages In a study conducted by the Cloud-Native Computing Foundation in 2020, 83% of respondents reported using Kubernetes as their container orchestration platform and 92% used containers in production. This demonstrates the increasing popularity of cloud-native techniques. IBM found that businesses utilising cloud-native technology experienced a 50% reduction in time-to-market for new applications and a 25% increase in developer productivity. This suggests that companies utilising CNA may gain substantial benefits. [Clo20] The components of CNA are independently deployable and upgradable services. Components are small, loosely coupled services and the connectors are the APIs and message protocols used by this design [Len12]. Modules in CNA are frequently organised by enterprise-relevant functionalities or domains. During development and deployment, each module is regarded as its own, independently scalable function. Using this method, developing, testing and deploying distributed applications is effortless [DL22]. CNA uses containerization and orchestration techniques to dynamically allocate resources based on the needs of each application[Lin17]. This method is well-suited for cloud deployment because it allows for dynamic resource allocation and efficient hardware utilisation. 2.2.4 Waterfall Software Development Since the 1970s, waterfall development methodology has been the industry standard. According to Ajmal and Ali (2016), the software is developed sequentially and each stage must be completed before proceeding [AA16]. The phases of waterfall software development are as follows: 1. During needs collection, project requirements are evaluated and documented. 2. The criteria from the previous phase are used to construct the architecture and design of the application. 3. Following software design, code is written to implement the plan. 24 2.2 Software Architecture Design Approaches 4. During testing, the software is evaluated to determine if it conforms to preexisting standards and criteria. 5. Deployment is responsible for preparing the production environment for software operation. Advantages Disadvantages Clear structure and documentation throughout the process [AA16] Little room for flexibility or changes during the development process [Sam19] Phases and milestones are well-defined, mak- ing it easier to manage and monitor progress [AA16] Testing is only done at the end, which can make it difficult to identify and fix issues earlier on [Sam19] Easier to estimate time and resources needed for each phase [Bas] Can lead to a slower time-to-market due to the sequential nature of the process [DM18] Clients and stakeholders have a clear under- standing of what to expect and when [Bas] Lack of collaboration between team members can lead to siloed work and less innovation [DM18] More suitable for projects with well- understood requirements and a fixed scope [Sam19] Can lead to a higher risk of project failure if initial requirements are incorrect or incomplete [AA16] Ineffective for developing complex software [AA16] Table 2.4: Waterfall Software Development - Advantages & Disadvantages The Waterfall model focuses on the sequential flow of activities, with each phase having specific tasks. It provides a framework for defining system requirements, identifying necessary components and their interactions. The identification of components and connectors occurs during the requirements gathering and analysis phase. The model does not explicitly prescribe a specific model structure, but system requirements are documented and analyzed during the early phases, which serve as a basis for creating high-level architectural models. The Waterfall model does not explicitly address allocation structure, but during later stages, the system is divided into smaller modules or components, which can be allocated to different development teams or individuals. [PWB09] 2.2.5 Domain-Driven Design In 2003, Eric Evans published “Domain-Driven Design: Addressing Complexity at the Heart of Software“, the first comprehensive DDD guidebook [Eva04]. DDD is a software development technique that emphasises business domain knowledge, domain modelling and communication with stakeholders. The development team and business stakeholders must reach a consensus on standardised terminology. Even when using specialised terminology, the language should be uncomplicated. This necessitates dividing the system into smaller, more manageable components. Each environment must have a scope-defining boundary. The phases of DDD are as follows [Nic15] [Ver13]: 25 2 Literature Review 1. Identifying the core domain of the system. This includes understanding the main purpose and unique aspects of the application that differentiates it from other systems. 2. Defining bounded contexts within the system. Bounded contexts help to clearly define and isolate different subdomains or components within the larger application, enabling better organization and separation of concerns. 3. Identifying and modelling the relationships and interactions between the different bounded contexts. This helps to ensure that the components within the system work together seamlessly and efficiently. 4. The final phase is the implementation phase, where the defined bounded contexts and their relationships are implemented in the actual system. This involves coding, testing and integrating the various components to create a functioning and cohesive application. Overall, the process of identifying the core domain, defining bounded contexts, modelling re- lationships and implementing the system is a crucial step in developing a successful software application. Advantages Disadvantages Encourages collaboration between domain ex- perts and developers [Ver13] High learning curve for developers unfamiliar with DDD [Eva04] Focuses on the core business logic and domain complexity [Eva14] Can be more time-consuming to implement compared to other approaches [Eva14] Helps prevent technical debt and maintainabil- ity issues [Abe07] Requires a solid understanding of the business domains [Nic15] Allows for greater flexibility and adaptability to changing business needs [Nic15] May require more testing and validation to en- sure business rules are accurately implemented [Abe07] Can lead to better scalability and modularity in complex systems [HH06] Can be over-engineered for simpler systems [HH06] Table 2.5: Domain-Driven Design - Advantages & Disadvantages Each bounded context encapsulates a distinct domain of the application and domain entities represent the domain objects and logic, in DDD’s C&C structure. Domain services, which offer a consistent set of functions within a limited context, are an example of module structures, while aggregates, which specify transactional consistency limits for a collection of domain entities, are an example of allocation structures. [MMCF18] [Nic15] 2.2.6 Service-Oriented Architecture When SOA is applied to the design of software architecture, applications can be viewed as a collection of services. Since these services are interoperable, Hustad & Olsen (2021) assert that they can be merged and reused to create more complex applications or to implement them into existing infrastructure [HO20]. SOA, according to Mishra and Sarkar (2022), is founded on a 26 2.2 Software Architecture Design Approaches design paradigm known as “service orientation“, which emphasises the production of modular, reusable and replaceable components [MS21]. Some of the SOA’s phases and approaches include the following [Erl] [MW07]: 1. The service identification phase entails identifying the architecture’s required services and analysing business requirements and procedures to determine which functionalities can be encapsulated. 2. The focus of service specification is the definition of specifications, such as inputs, outputs, behaviour, constraints and policies. 3. Service realisation entails translating the architectural design into actual implementation, choosing suitable technologies and frameworks and defining data models and communication interfaces. 4. The deployment of a service entails setting up servers or cloud environments, configuring networking and security settings and ensuring that all dependencies are implemented correctly. 5. Followed by service monitoring and management, which includes monitoring performance metrics, administering service updates, addressing scalability concerns and ensuring efficient resource allocation. Advantages Disadvantages Services can be developed and deployed inde- pendently and reused across multiple applica- tions [KK09] The architecture is complex and requires sig- nificant planning and design [Law04] The modular design of SOA allows for scaling of individual services as needed [MBKN09] The added layers and communication between services can impact performance [MBKN09] Services can be added, removed or modified without affecting the entire system [RGKS20] Integration with non-SOA systems can be chal- lenging [NIG+20] Services can be deployed on different platforms and locations, increasing availability [NIG+20] Effective governance is needed to ensure con- sistency and adherence to standards [KK09] Table 2.6: Service-Oriented Architecture - Advantages & Disadvantages Connectors in SOA are the communication protocols and mechanisms that permit interaction between services. Using standardised protocols like Simple Object Access Protocol (SOAP) and REST over Hypertext Transfer Protocol (HTTP), they facilitate data exchange and collaboration. Components are independent services, whereas connectors facilitate their interaction. A module is a logical unit that incorporates a specific set of functionalities or business processes in the context of SOA. A module is typically a cohesive and independent element of code that is responsible for implementing a particular aspect of the functionality of a service. On various physical or virtual machines, containers or cloud platforms, services can be deployed. The allocation structure takes scalability, performance, defect tolerance and resource utilisation into account. [NIG+20] [PH07] 27 2 Literature Review 2.2.7 Event-Driven Architecture EDA software design encourages the production, monitoring and processing of system-level events. Events are occurrences that have a significant effect on the system or its procedures. EDA decoupling enables events to communicate across components that may be geographically distant. This strategy increases the adaptability and scalability of the system. [IE06][BD14] Typically, event detection and analysis consist of four steps: [IE06]. 1. The event detection stage focuses on identifying system-relevant events as a first step. 2. In the second phase, event routing is taking place where message intermediaries and publish-subscribe systems are employed. 3. The third stage involves gaining insight from the event and selecting future actions. 4. In the persistence phase, events are stored for auditing or additional analysis. Advantages Disadvantages Highly scalable and flexible [CB12] Complex to design and implement [DW05] Supports real-time processing and asyn- chronous communication [DW05] Requires extensive event logging and monitor- ing [CB12] Decouples components and allows for indepen- dent development and deployment [CB12] Difficult to debug and troubleshoot [IE06] Enables event-driven workflows and business logic [Woo21] Inconsistent performance due to variable event processing times [IE06] Can handle large volumes of data and events [CB12] Difficult to maintain consistency and transac- tional integrity [IE06] Promotes modularity and reuse of components [DW05] Requires specialized tools and expertise [DW05] Supports distributed and cloud-based systems [Woo21] Can result in a high number of redundant events [DW05] Can improve system responsiveness and agility [Woo21] Can result in increased network traffic and latency [IE06] Table 2.7: Event-Driven Architecture - Advantages & Disadvantages Components in an EDA are typically categorised as either event producers or event consumers and are connected via an event bus or message broker. Instead of considering the typical control flow between components, the event-driven method focuses on the flow of events and the responses to those events. Each module in an EDA system may contain multiple event producers and consumers, with business capabilities serving as the organising principle. Allocation structure in EDA refers to the distribution and assignment of event producers, event consumers and event processing components within the architecture. [IE06] [Woo21] 28 2.2 Software Architecture Design Approaches 2.2.8 Model-Driven Architecture MDA is a software development methodology that emphasises the use of models as the primary artefacts for designing, defining and generating software systems. It provides a framework for distinguishing the functionality of a system from its implementation. [09] In MDA, the development process revolves around models, which are abstraction-level-specific representations of the system. These models encapsulate the essential structure, behaviour and functionality of the system. They serve as a common language for stakeholders such as business analysts, developers and architects. [MAC+04] MDA has several distinct phases, including the following [09] [GYE22]: 1. During the requirements collection phase, every need that the system must fulfil is meticulously mapped out. 2. During the platform-independent modelling phase, a domain-specific modelling language is used to convert the system requirements into Platform-Independent Model (PIM). 3. Automated model transformations are used to convert PIMs into Platform-Specific Model (PSM). These PSMs are then utilised in later modelling phases. 4. During the phase labelled “code generation“ the PSMs are converted into machine-readable code. Advantages Disadvantages Automates repetitive tasks [Bro04] Requires initial investment in MDA tools [Joh01] Improves development productivity [GYE22] Learning curve for MDA tools can be steep [GYE22] Provides consistency across the system [Sol00] Can be difficult to integrate with legacy systems [AJW03] Promotes code reuse and maintainability [Bro04] May be less flexible than traditional develop- ment [Joh01] Simplifies maintenance and updates [MAC+04] May require additional effort for customization [09] Enables faster time-to-market [GYE22] May not be suitable for all project types [Bro04] Table 2.8: Model-Driven Architecture - Advantages & Disadvantages MDA prioritises model structure over defining C&C structures. C&C can be represented as encapsulated units of functionality with well-defined interfaces, with connectors serving as means of communication and interaction. Modelling languages, such as UML, offer constructs for modelling C&C, which depict architectural structure and relationships. MDA differentiates PIM and PSM, enabling hierarchical relationships and transformations. MDA’s allocation structure incorporates the distribution and allocation of system components and resources across the target architecture. It provides a framework for capturing allocation influencing system requirements and design decisions. This data can direct code generation or deployment processes to reflect the allocation of system components and resources. [09] [AJW03] 29 2 Literature Review 2.2.9 Reactive Architecture In modern software systems, Reactive Architecture is an architectural approach that prioritises responsiveness, scalability and resilience. It emphasises managing and responding to large numbers of concurrent and asynchronous events while maintaining a consistent user experience. Responsive- ness, message-driven and event-based communication, elasticity and scalability, resilience, reactive streams and backpressure, event sourcing and Command Query Responsibility Segregation (CQRS) are key characteristics of reactive architecture. [DSM+17] Reactive architecture prioritises delivering a high-quality user experience while guaranteeing the stability and responsiveness of contemporary software systems. The following are typical phases of the reactive architecture approach [AA15] [Sob10] [Tov19b]: 1. Collecting and analysing the application’s functional and non-functional requirements, performance expectations and scalability needs. 2. Using modelling techniques such as event storming or domain-driven design for identification of the system’s key components, data flows, interactions and relationships. 3. Reactive architecture significantly depends on event-driven design principles and emphasises the utilisation of reactive components and patterns. 4. Data management is essential for effective data management and techniques such as distributed databases, cache and stream processing are utilised. 5. Introduce mechanisms like fault-tolerant clustering, replication and self-healing capabilities, reactive systems should be able to gracefully manage failures and maintain high availability. 6. Deployment and scaling are crucial stages in deploying the application to the desired environment, including configuring infrastructure, establishing deployment pipelines and scaling the system horizontally or vertically to accommodate increasing load or demand. 7. Continuous monitoring of a system’s health and efficacy requires monitoring and optimisa- tion. Analysing collected data aids in identifying bottlenecks, optimising performance and enhancing overall productivity. 30 2.3 Software Architecture Design Approaches Comparison Advantages Disadvantages Highly responsive and resilient [ELV+12] Requires significant expertise to design and implement [DSM+17] Scalable and adaptable to changing require- ments [Tov19b] Increased communication complexity and po- tential for errors [Tov19b] Promotes loose coupling and better separation of concerns [SAM+19] Increased network overhead [AA15] Efficient use of resources [AA15] Debugging and tracing can be challenging in distributed systems [Tov19b] Supports event-driven and real-time systems [SAM+19] Not suitable for all types of applications or systems [SAM+19] Promotes modularity and reusability [AA15] Difficulty in testing and validating the system as a whole [AA15] Table 2.9: Reactive Architecture - Advantages & Disadvantages Connectors are the means through which two or more components may exchange data with one another in Reactive Architecture, with components themselves being tiny, self-contained and autonomous entities. Connectors in Reactive Architecture are often event-driven, allowing for non-blocking, asynchronous communication between components. Module organization in Reactive Architecture often borrows ideas from microservices architecture, which breaks down large systems into smaller, more manageable components. Services in a Reactive Architecture are often implemented using a distributed allocation structure that optimizes performance and availability and scales quickly to meet fluctuating demand. [DSM+17] [Tov19b] [AA15] 2.3 Software Architecture Design Approaches Comparison Overall advantages, disadvantages and key features of all approaches are presented in following Table 2.10. Approach Advantages Disadvantages Key Features Architecture Centric De- sign Modularity, flexibility, reusability, interoperabil- ity, better system un- derstanding, system-wide consistency Difficult to accommodate late changes, requires sig- nificant upfront design, may be over-engineered for smaller projects Components, connectors, interfaces, design pat- terns Micro- services Architec- ture Scalability, agility, re- silience, independent deployment, reusabil- ity, fault isolation and resilience Complexity of testing, op- erational overhead, la- tency and overhead of net- work calls Services, API based com- munication, load bal- ancer, small and decou- pled services, container- ization Continued on next page 31 2 Literature Review Table 2.10 – Continued from previous page Approach Advantages Disadvantages Key Features Cloud- Native Architec- ture Scalability, high availabil- ity, fault tolerance, porta- bility, cost efficiency (pay- as-you-go) Complexity of orchestra- tion, requires learning new tools, security con- cerns, vendor lock-in Leveraging cloud ser- vices and platforms or- chestration, service dis- covery, immutable infras- tructure Waterfall Software Develop- ment Well-defined phases, pre- dictable outcomes, clear documentation, rigorous control, suitable for small projects Limited flexibility, diffi- culty adapting to change, poor collaboration Sequential development, comprehensive documen- tation Domain- Driven Architec- ture Modular design, im- proved communication, agile development, flex- ibility May require significant refactoring of existing code, complexity of im- plementation, Learning curve for DDD concepts Bounded contexts, ubiqui- tous language, aggregates entities Service Oriented Architec- ture Interoperability, scalabil- ity, reusability, maintain- ability, flexibility Complexity of orchestra- tion, service bloat, cou- pling of services Loose coupling, standard- ized communication, fo- cus on service and inter- faces Event- Driven Architec- ture Scalability, loose cou- pling, extensibility, re- sponsiveness, traceability, fast responses Debugging can be chal- lenging, eventual consis- tency, complexity of data flow Event bus, event sourc- ing, event-driven messag- ing (produces and con- sumer) Model Driven Ar- chitecture Reusability, consistency, automation, improved communication, adapt- ability to changes Requires significant up- front design, learning curve, may be over- engineered for smaller projects Models, transformations, metamodels, platform in- dependent modelling Reactive Architec- ture Scalability, responsive- ness, fault tolerance, high performance Complex to implement, requires skilled develop- ers, debugging can be challenging Actors, streams, message driven communication, CQRS, asynchronous pro- cessing Table 2.10: Architectures - Advantages & Disadvantages & Key Features 2.4 Software Architecture Design Approaches Ranking based on Non-Functional Requirements One of the major characteristics of deciding on a software architecture approach is the non-functional requirement evaluation. 32 2.4 Software Architecture Design Approaches Ranking based on Non-Functional Requirements As discussed in Section 2.1 the nine non-functional requirements are evaluated regarding to the architecture approaches. These variables aid in assessing and contrasting the efficacy of various architectural strategies in achieving the required levels of these traits. In this section, an assessment is conducted, followed by the construction of a matrix (Table 2.11) wherein evaluation scores, ranging from 1 to 5, are assigned to each architecture method. A score of 1 corresponds to a poor grade, while a score of 5 denotes an excellent grade. 2.4.1 Non-Functional Requirements Evaluation for Architecture Centric Design Through the use of redundant components and systems, fault tolerance techniques and load balancing techniques, architecture-centric design ensures availability. These measures guarantee continuous operation in the event of a failure and evenly distribute the workload across multiple resources. However, improper maintenance or testing of redundancy mechanisms can result in system failure and load-balancing techniques may not always prevent component overburden in the presence of unpredictable or unequally distributed workloads. [Dev17] Availability Grade: 4 Scalability is achieved via modular components and adaptable infrastructure. By decomposing a system into smaller, independent components, this method enables systems to accommodate increased workloads and adapt to shifting requirements. A well-designed architecture has a flexible infrastructure that permits the addition or withdrawal of resources without affecting the system as a whole. Due to significant modifications and potential outages or performance disruptions, it may be difficult to scale a monolithic architecture where components are tightly coupled. [Dev17] Scalability Grade: 4 The procedures ensuring availability also guarantee continuous operation and eliminate singular points of failure. On the other hand, they may encounter obstacles when systems rely on volatile or unreliable external resources, resulting in deployment and maintenance difficulties. [DL01] Deployability Grade: 4 Standardised interfaces and protocols are essential for architecture-centric design’s integrability. Components can interact based on agreed-upon protocols by designating clear communication interfaces, such as APIs or service contracts. However, interface incompatibilities and conflicts can impede seamless integration. Custom adapters or middleware may be required to ensure interoperability and compatibility between components by bridging the communication gap between them. [GPNV02] Integrability Grade: 4 Beginning the design process with performance in mind simplifies the achievement of performance objectives. By including performance as a primary requirement, design decisions and compromises can be made with performance in mind. Architecture-centric design often leverages well-known architectural patterns, best practices and technologies such as caching, load balancing and asyn- chronous processing can facilitate performance optimisation. [Bos04] Performance Grade: 5 Modular architecture promotes testability by decomposing the system into independent, loosely coupled components that can be isolated and tested separately. Well-defined interfaces enhance testability by facilitating the replacement of external dependencies with controlled test data. 33 2 Literature Review Nevertheless, this method may introduce additional complexities, such as dependency injection, test-friendly interfaces and additional abstraction layers. Managing this complexity can be difficult, particularly when it compromises the architecture’s clarity and simplicity. Test maintenance is essential for preserving the efficacy and currency of the architecture over time. [RJ06] Testability Grade: 3 By establishing a clear architecture and supplying well-defined guidelines, developers are better able to comprehend architectural principles and design constraints. Clear guidelines on component responsibilities, communication patterns and data flows allow developers to make well-informed design decisions and create software that conforms to the architecture. [RJ06] Ease of Development Grade: 5 Modifiability in architecture-centric design involves using modularity, component-based design, separating concerns, minimizing coupling, providing open extension points, abstraction, encap- sulation, leveraging design patterns, continuous refactoring and documentation sharing. These key points enable flexible, adaptable and easily modifiable architecture. Balancing complexity without hindering understandability or performance can be challenging and design decisions to enhance modifiability may impact system performance, as loose coupling or abstraction layers can add overhead to the system. [GPNV02] Modifiability Grade: 3 Architecture-centric design prioritises user requirements, incorporates principles and provides user-friendly interfaces, efficient workflows, explicit documentation, user testing and feedback. Understanding requirements, conducting research, designing intuitive interfaces, simplifying complex processes, providing documentation, tutorials and responsive support, as well as perpetually iterating based on user feedback to improve system usability and user experience, are essential elements. [Bos04] Usability Grade: 5 2.4.2 Non-Functional Requirements Evaluation for Microservices Architecture The approach microservices architecture incorporates availability through redundancy, load balanc- ing, failover, circuit breaker and monitoring and alerting. Even in the event of faults or failures, these strategies ensure that the system remains operational and accessible to its users. [WLS22] Availability Grade: 5 The best possible grade for scalability was awarded to the microservices architecture since it allows for highly scalable and flexible service deployments through its loosely coupled, independent and exchangeable components. [Dav21] Scalability Grade: 5 The continuous and simple deployment of individual services earned a good evaluation in the deployability category. One counterargument to the evaluation of deployability is that managing and deploying a large number of individual services can become complex and time-consuming, potentially leading to deployment errors or delays. [BQT22] Deployability Grade: 4 34 2.4 Software Architecture Design Approaches Ranking based on Non-Functional Requirements The loose coupling and straightforward API and message-based communication fostered by microser- vices architecture earned it a good grade in the integrability category However, a counterargument to the microservices architecture’s evaluation in integrability is that coordinating and maintaining the interactions between numerous services can become challenging, potentially resulting in compatibility issues or communication failures. [AC22] Integrability Grade: 4 Microservices architecture permits great performance via the usage of lightweight and focused services. Since each microservice could be scaled independently and therefore adapt to the varying workload, it can increase its performance by acquiring computational power on heavy-duty tasks. [AC22] Performance Grade: 5 With this approach, it is possible to test each service separately and additionally encourages automated testing. However, testing each service separately does not guarantee that the overall system will perform well when the services are interconnected and automated testing may not capture all possible issues that can arise in complex systems. [WLS22] Testability Grade: 4 Since it encourages the creation and deployment of services independently, microservices architecture received a high grade for development simplicity. However, this independence can lead to difficulties in coordinating and managing the interactions between different services, resulting in added complexity and potential integration issues. [WLS22] Development Simplicity Grade: 4 It encourages modularity and permits simple adjustment of specific services without impacting the overall system. However, this modularity can also lead to a higher maintenance burden as changes made to one service may require adjustments in other services that interact with it, potentially increasing complexity and integration challenges. [Dav21] Modifiability Grade: 4 The design can enhance the user experience by allowing for greater flexibility, customisation and personalisation of services. A microservices architecture can facilitate the application of user-centric design principles, such as user personas, user stories and user feedback, to guide the development of individual microservices. [BQT22] Usability Grade: 5 2.4.3 Non-Functional Requirements Evaluation for Cloud-Native Architecture Availability is crucial for creating durable, controllable and observable loosely connected systems. However, there are instances where availability can be compromised, such as when a cloud provider experiences a major outage or system failure, causing widespread disruptions for users and businesses. [Lin17] Availability Grade: 4 Scalability is achieved through containerization and orchestration technologies, which allow for automatic scaling of resources based on demand. This feature enables applications to efficiently handle varying levels of traffic and adapt to changing business needs. [R G22a] Scalability Grade: 5 35 2 Literature Review Depolyability is crucial for easy application deployment across different environments. Container- ization enables easy packaging and deployment of applications, but it can be counterproductive in cases where external dependencies or resources are not easily containerized. Complex configuration changes and setup may introduce delays and errors during deployment. [Lin17] Deployability Grade: 4 Promoting the use of microservices and APIs to enable independent development and communication between components. However, a lack of proper documentation or standardization in the development process can lead to inconsistencies in APIs and communication protocols, leading to errors and failures during the deployment process. [DL22] Integrability Grade: 4 Advocating the utilization of automation and monitoring tools to enhance performance and address bottlenecks is paramount. Nevertheless, it is important to note that a cloud-native application that lacks performance optimization may still encounter challenges related to scalability and overall performance. [R G22c] Performance Grade: 4 Facilitating seamless and effective testing is achieved through the implementation of automated testing, containerization orchestration technologies, and modular components. However, it should be noted that complex architectures often lack distinct boundaries, which poses challenges in isolating and testing individual components. CNA principles may not include proper testability practices, such as modular components or automated testing. This can cause inefficient testing processes and negatively impact the application’s overall quality. [R G22b] Testability Grade: 3 It offers ease of development through containerization and orchestration technologies, simplifying deployment and testing for developers. However, dealing with complex microservices can be challenging due to their interconnected nature. This complexity can result in longer development cycles, increased debugging efforts and increased risk of introducing bugs or errors during deployment. [Tel22] Ease of Development Grade: 3 Modifiability is achieved through containerization and orchestration technologies, such as Docker and Kubernetes, which enable the deployment and management of microservices independently. However, achieving modifiability through these technologies does not guarantee a seamless deployment process, as complex interdependencies between microservices or multiple updates simultaneously can still be challenging and prone to errors. [Lin17] Modifiability Grade: 4 Usability is another aspect, incorporating intuitive user interfaces, clear documentation and robust monitoring and troubleshooting tools. However, even with these measures in place, there may still be instances where the usability of a CNA falls short. [DL22] Usability Grade: 4 36 2.4 Software Architecture Design Approaches Ranking based on Non-Functional Requirements 2.4.4 Non-Functional Requirements Evaluation for Waterfall Software Development To prioritize availability-related decisions during the design phase, it is crucial to consider redundancy, fault tolerance, scalability, and backup and recovery mechanisms. Implementing failover strategies, load balancing techniques, and appropriate hardware or software architectures are key to maximizing system availability. However, the rigid and sequential nature of the cascade methodology can hinder the timely identification of availability issues, which may only surface during the testing phase. Furthermore, the waterfall methodology lacks a continuous feedback cycle between development and operations teams, resulting in delayed feedback on observed availability issues in production environments. [AA16] Availability Grade: 3 Prioritising scalability during the requirements gathering phase by working closely with stakeholders to identify potential requirements such as user traffic, data volume and performance requirements. Considering load balancing, caching, vertical and horizontal scaling and database partitioning as scalability patterns. Changes in scalability requirements or the emergence of new factors can make it difficult to alter the design and implementation phases to accommodate these modifications. [AA16] Scalability Grade: 4 Defining deployment requirements during the requirements gathering phase, including target envi- ronments, hardware specifications, operating systems and constraints. Performing pre-deployment testing in a staging environment that closely resembles the production environment in order to verify the process and validate the functionality of the software. The waterfall methodology has limited iterative feedback and adaptability, making it challenging to incorporate deployment related feedback-based changes. [DM18] Deployability Grade: 3 Specify inputs, outputs, communication protocols and data formats with precision to ensure compatibility and interoperability. Stable, standard protocols and data formats, such as REST API or Extensible Markup Language (XML)/JavaScript Object Notation (JSON), facilitate the seamless integration of components or systems. As each phase is concluded before moving on to the next, iterative integration can be difficult, causing delays in identifying and resolving issues and making it more difficult to achieve a seamless integration. [Sam19] Integrability Grade: 3 Defining performance requirements, such as response time, throughput and resource utilisation and take into account variables such as data structures, algorithms, caching mechanisms and system scaling. Reducing computation, reducing resource contention and using appropriate data structures while optimising code for efficiency. The waterfall methodology follows a sequential, linear approach, which limits performance enhancement flexibility. Changes to the design, architecture or implementation may necessitate extensive revision or delay the completion of the project. [Sam19] Performance Grade: 3 Testability requires specific, measurable requirements for the efficient development and evaluation of test cases. Prioritising the allocation of time for test planning and design, determining testing scope, defining objectives and developing a comprehensive test plan. Waterfall methodology, which 37 2 Literature Review is frequently implemented at the conclusion of the development process, can result in a lack of resources and make it difficult to resolve defects and issues discovered during testing. [Bas] Testability Grade: 3 It is essential to have well-documented, clear and unambiguous requirements for a software development process to run smoothly. This makes it easier for developers to comprehend and implement the software. It is essential to invest time and effort in the design and planning phases, as they guide the development process and help developers comprehend system architecture and component interactions. The sequential, linear nature of the waterfall methodology makes it difficult to incorporate changes or modifications. In addition, delayed validation can lead to the identification of issues after substantial development effort has been invested, resulting in rework, additional effort and delays in achieving the desired development simplicity. [Bas] Ease of Development Grade: 2 Inflexible modifications can hinder the software’s modifiability, as they may necessitate extensive revision or disrupt project timelines. Waterfall methodology delays change identification until later phases, limiting consideration of changes during testing or deployment. Additionally, a lack of iterations hinders the software’s modifiability. [PWB09] Modifiability Grade: 1 Involving end users and stakeholders in the initial phases of the design process in order to comprehend their requirements, preferences and workflows. Ensure that requirements are distinct and that functionality, interfaces and interactions are defined. A sequential, linear methodology, waterfall may restrict iterative design and refinement of usability aspects. [DM18] Usability Grade: 4 2.4.5 Non-Functional Requirements Evaluation for Domain-Driven Design DDD emphasises ensuring accessibility via techniques and principles, such as bounded contexts and asynchronous communication patterns. Bounded contexts define distinct boundaries and responsibilities within a system. This entails determining which portions of the system must be available at all times and which can tolerate some downtime. DDD also encourages asynchronous communication, which enables components to exchange data without impeding or waiting for responses. Nevertheless, separating a system into bounded contexts may result in data inconsistency and synchronisation problems, as changes made in one context may not propagate instantaneously to other contexts. [Nic15] Availability Grade: 4 Using bounded contexts DDD accomplishes scalability. These contexts can scale independently to accommodate increased demand and traffic without affecting other contexts. Nonetheless, scaling one bounded context may impact other contexts due to conflicts and discrepancies in shared data, posing coordination challenges and the possibility of inconsistencies in the system’s overall state. [Eva14] Scalability Grade: 4 38 2.4 Software Architecture Design Approaches Ranking based on Non-Functional Requirements DDD achieves deployability by its manageable bounded contexts, each focusing on a specific subdomain. However, deployability can be challenging if interdependencies exist between these contexts. For instance, if one context requires data from another, changes in the dependent context can affect the entire system’s deployability. [Ver13] Deployability Grade: 3 Utilising integration patterns and techniques to manage interdependencies between bounded contexts effectively ensures integrability. Among these are mechanisms for defining interfaces, contracts, messaging, EDA and data synchronisation. On the other hand, the lack of distinct boundaries and communication protocols can result in conflicts, inconsistencies and system instability. Inadequate integration patterns and methods can also lead to performance and scalability issues. [Nic15] Integrability Grade: 3 Analyzing the domain model helps identify potential bottlenecks and high computational com- plexity areas, allowing developers to optimize them. Domain-specific optimizations, like caching or precomputing data, minimize repetitive calculations and reduce response times. However, these optimizations may introduce additional complexity and maintenance overhead, potentially outweighing potential performance gains in certain scenarios. [Ver13] Performance Grade: 3 Separating concerns enables the isolation of domain logic from infrastructural dependencies, allowing unit tests to concentrate on the model’s behaviour without requiring external systems or databases. This method also permits the substitution or simulation of dependencies during testing. But separating domain logic from infrastructure may increase development and maintenance complexity and overhead. [Eva14] Testability Grade: 3 Ease of development is enabled by focusing on a clear, well-defined domain model, allowing developers to focus on core business logic without infrastructure concerns. Encapsulating domain logic within entities, value objects and aggregates improves code understanding and modification, leading to faster development cycles. Ubiquitous language and domain experts’ involvement ensure accurate code reflects business requirements. This approach can make the codebase more complex and harder to maintain, especially with frequent changes or updates. Additionally, relying heavily on domain experts may limit system flexibility and adaptability in response to changing business needs. [Eva04] Ease of Development Grade: 2 The modular approach allows developers to modify and evolve a system’s domain logic without disrupting other parts. Domain events and event sourcing enhance modifiability by capturing and storing change history. However, this approach may not be suitable for complex interdependencies, as changes may affect other domains, causing unexpected behaviour and difficult debugging. Additionally, domain events and event sourcing introduce complexity and overhead, making the system harder to understand and maintain for developers unfamiliar with these concepts. [Abe07] Modifiability Grade: 3 Each bounded context focuses on a specific aspect of the system’s functionality and has its own well-defined language and set of models. This allows developers to have a clear understanding of the domain they are working on and enables them to build intuitive and user-friendly interfaces that align with the users’ mental models. [Abe07] Usability Grade: 4 39 2 Literature Review 2.4.6 Non-Functional Requirements Evaluation for Service-Oriented Architecture SOA assures availability through mechanisms and best practices, including redundancy and fault tolerance techniques. Multiple instances of services operate simultaneously, ensuring system continuity even if one fails. Load balancing ensures optimal performance and availability by distributing incoming requests equitably. [Law04] Availability Grade: 5 The architecture uses load balancing and caching mechanisms to improve scalability by evenly distributing requests and reducing service burden. Microservices architecture breaks down complex applications into independent services, allowing flexibility and agility in scaling based on demand. SOA, on the other hand, emphasizes loose coupling and interoperability between services. [KK09] Scalability Grade: 4 SOA encourages loose coupling between services, enabling each service to be independently developed and deployed without affecting the overall system. Services are accessed via standardised protocols such as HTTP, SOAP or REST, allowing for simple platform and technology integration. Service registries are also utilised by SOA to facilitate discovery and deployment. However, SOA can be undermined when services have significant dependencies on each other’s data structures or interfaces, causing changes to a service’s data structure or interface to have an effect on all dependent services and thus contradicting the concept of independent development and deployment. [Erl] [MW07] Deployability Grade: 4 Integrability Grade: 5 Performance is achieved through optimizing communication between services, minimizing latency and overhead, using efficient protocols, lightweight data formats and reducing network round trips. Caching mechanisms store frequently accessed data and load balancing and horizontal scaling distribute workload across multiple instances, improving overall system performance. Despite efforts to minimize latency and overhead in message passing, certain situations may not be feasible. For instance, in highly distributed systems with geographically dispersed nodes, physical distance can introduce network delays and increase latency. [Law04] Performance Grade: 4 Designing services with distinct interfaces and boundaries facilitates the isolating and testing of individual components. Standard protocols such as SOAP and REST make testing easier. Injection of dependencies and inversion of control help decouple services, making them easier to evaluate. However, the use of non-standard or custom protocols can impede the testing process, as it may necessitate additional effort to develop and maintain specific testing frameworks. [Law04] Testability Grade: 4 SOA development can be facilitated by strategies such as modular design, which permits services to be developed and deployed independently and standard protocols, which provide a common language for communication and interoperability among services. [PH07] Ease of Development Grade: 5 In SOA, modifiability is accomplished via service contracts, which define the interface and behaviour of a service. These contracts permit autonomous evolution that does not influence other dependencies. Loose coupling and abstraction reduce the influence of modifications on other components. In contrast, when there is a tightly coupled service dependency, minor changes 40 2.4 Software Architecture Design Approaches Ranking based on Non-Functional Requirements can cascade across multiple dependent services, making the process complex and prone to error. [NIG+20] Modifiability Grade: 4 It focuses on simplicity and ease of use through clear interfaces, well-documented APIs and comprehensive user documentation. Interoperable services enable seamless integration and interaction with other services. Standard protocols and formats enhance usability by facilitating communication and data exchange between architecture components. [MBKN09] Usability Grade: 5 2.4.7 Non-Functional Requirements Evaluation for Event-Driven Architecture Through distributed systems and fault-tolerant mechanisms, availability is ensured. Implementing redundancy permits multiple event processors to be deployed across multiple nodes, thereby minimising downtime and guaranteeing uninterrupted service. Event-driven systems additionally employ message queues or archives to store and buffer incoming events, ensuring scalability and resilience against traffic spikes or event volume spikes. [CB12] Availability Grade: 5 EDA achieves scalability through techniques like distributed systems, message queues and event logs. These systems distribute workload across multiple processing units, allowing them to handle higher event volumes. However, a counterexample to scalability is when a single node becomes overloaded with events, causing a bottleneck. [DW05] Scalability Grade: 4 EDA accomplishes deployability via containerization and microservices, separating the system into independent units for simple deployment and scalability. This modular design increases the system’s flexibility and adaptability to change. Event-driven system deployment necessitates managing multiple components, ensuring proper configuration and managing dependencies, posing complexities and increasing the likelihood of errors. [DW05] Deployability Grade: 3 It accomplishes integration via event-driven messaging systems and application programming interfaces. APIs provide a standard interface for integrating external systems or services, whereas these systems enable seamless communication between components. Yet, outages or unavailable messaging systems can disrupt the flow of information, resulting in data inconsistencies and system failures. [IE06] Integrability Grade: 4 EDA accomplishes performance via asynchronous messaging, parallel event processing and component decoupling for enhanced responsiveness. However, it may not be the best option in situations such as financial transactions where the precise order of events is essential. The asynchronous nature of messaging can lead to problems with consistent event order and debugging and troubleshooting can be complicated by the management of multiple independent components. [BD14] Performance Grade: 3 41 2 Literature Review Testability in EDA entails simulating external system or dependency behaviour with mock or stub components during testing. This permits developers to test individual components in a controlled environment. Frameworks for automated testing validate the response and behaviour of a system while monitoring and logging tools to trace event flow. However, there may be circumstances in which the behaviour of an external system or dependency cannot be readily replicated or controlled in a testing environment, such as when relying on real-time data from an external API. Event-driven systems require thorough testing and debugging to ensure correct behaviour and interactions across components and services, as events may be distributed and asynchronous. [Woo21] Testability Grade: 3 By decoupling components and using event-driven messaging, EDA simplifies development. This approach allows developers to concentrate on individual components or services without having to consider their interactions. This modular approach promotes code reuse and scalability by allowing components to be replaced or added as necessary. However, when there are too many events and handlers, it becomes more difficult to monitor dependencies and interactions, which can lead to bugs and inconsistencies. [IE06] Ease of Development Grade: 4 It decouples events and handlers, allowing one component to be modified independently of the others. Flexibility and adaptability in a system are essential but can be difficult to maintain efficiently when synchronous communication is extensively utilised. Tightly coupled architectures can cause ripple effects throughout the entire system and adding or removing new events and handlers may necessitate substantial modifications to existing components, thereby limiting flexibility and adaptability. [IE06] Modifiability Grade: 3 Event processors are crucial for determining the behaviour and responsiveness of a system. Designers should create handlers that are both intuitive and efficient to facilitate ease of use and navigation for the end users. Clear documentation and guidelines enhance efficacy by assisting users in comprehending how to interact with the system effectively. [Woo21] Usability Grade: 5 2.4.8 Non-Functional Requirements Evaluation for Model-Driven Architecture The modelling phase may incorporate redundancy considerations, such as duplicating critical components or services, instituting failover mechanisms or employing load-balancing techniques. Availability is a complex characteristic that requires fault tolerance, redundancy, failover mechanisms and recovery strategies. It can be difficult to precisely and effectively model these aspects using available abstractions. In some instances, modelling languages and tools may lack the necessary expressiveness to convey the complexities of availability. [Bro04] Availability Grade: 3 MDA abstracts and separates scalability concerns such as load balancing and partitioning by utilising models to represent various system components. This methodology emphasises automated code generation based on models, allowing for the construction and deployment of scalable components or services using code generators and deployment tools. Modelling languages and tools for capturing scalability requirements and mechanisms have limitations. Traditional models emphasise 42 2.4 Software Architecture Design Approaches Ranking based on Non-Functional Requirements design-time modelling and code generation, which may not support real-time adaptation and therefore limit dynamic scale systems in response to changing conditions. [Sol00] Scalability Grade: 3 Well-defined and automated model transformations and code generation procedures are essential for transforming models into deployable artefacts for target deployment platforms. The tools and platforms for creating, transforming and deploying models may have their own requirements and dependencies, which can create complications when moving or deploying models across various environments or updating to newer versions. [09] Deployability Grade: 4 The standardization of modelling languages, notations, and frameworks provides significant benefits to MDA. It ensures interoperability among various tools, platforms, and systems, promoting seamless communication and integration between them. MDA can aid in the generation of API definitions and the corresponding code or configuration files. Modelling languages again may have limitations when it comes to expressing integration-related concepts. [MAC+04] Integrability Grade: 4 Using techniques such as queuing models, state models and performance annotations can enhance performance. Runtime performance monitoring and optimisation mechanisms, collecting data to identify bottlenecks, detect anomalies and initiate optimisations or auto-scaling actions are possible. However, model transformations can introduce additional latency, such as processing time, memory consumption or code complexity. In addition, modelling languages can limit the ability to encapsulate performance requirements in their entirety. [AJW03] Performance Grade: 3 Testability considerations are incorporated into the modelling process by designing testable models, such as by separating concerns, modularizing components and defining explicit interfaces. However, it can be difficult to generate tests from complex models, particularly when they are large or intricate. Developing automated processes that accurately reflect the system’s behaviour and encompass all relevant scenarios can have an effect on the system’s overall testability. [Joh01] Testability Grade: 4 Utilize intuitive modelling languages and low learning curves to simplify system requirements, behaviour and structure. MDA introduces new tools and concepts, which can be steep for developers unfamiliar with them. Complex tool interfaces and languages can further complicate learning and development. Debugging and troubleshooting generated code or artefacts can be more complex in MDA compared to traditional coding approaches, affecting diagnosing and resolving issues during development. [GYE22] Ease of Development Grade: 3 Designing models that encourage abstraction and concern separation, delineating the responsibilities and interactions of various system components. This permits autonomous modification without affecting the system as a whole, thereby enhancing its modifiability. However, modelling languages used in MDA may have limitations. Additionally, compatibility and interoperability between tools and platforms can have a negative effect on the modifiability of generated artefacts, making it difficult to employ newer versions. [Bro04] Modifiability Grade: 3 43 2 Literature Review Using user-friendly and intuitive modelling languages and tools with plain syntax and an intuitive interface. Focusing on user-centred design principles, taking into account user preferences, requirements and abilities. Creating interactive tools that provide immediate feedback and identify potential errors or inconsistencies. Modelling tools in MDA may be limited by a lack of features, performance issues or compatibility issues. [AJW03] Usability Grade: 5 2.4.9 Non-Functional Requirements Evaluation for Reactive Architecture Reactive architecture incorporates availability by designing systems to be highly resilient and handle failures using techniques like replication, load balancing and fault tolerance. This ensures high availability and responsiveness by distributing the workload across multiple instances and isolating failures without affecting the overall system. [AA15] Availability Grade: 5 It emphasizes scalability by designing systems to handle increasing workloads and adapt to changing demands. Techniques like horizontal scaling distribute workload across nodes, ensuring capacity increases without compromising performance. It promotes asynchronous communication patterns, enabling simultaneous handling of multiple requests and improving overall performance. However, when horizontal scaling is not effectively implemented it can result in decreased performance and responsiveness rather than scalability. [Tov19b] Scalability Grade: 4 Deployability is achieved through containerization and orchestration technologies, enabling seamless system scaling. Nevertheless, reactive systems rely heavily on third-party dependencies or external services, which can impact deployability. Critical dependency failures or performance issues can lead to deployment failures or degraded system performance. [DSM+17] Deployability Grade: 4 Through well-defined APIs integrability is accomplished, which enables seamless data and message exchange between components and services. Event-driven communication patterns and asynchronous messages indicating changes or actions, also contribute to seamless integration. However, tightly coupled systems, where components and services are heavily dependent on each other’s implementation details, hinder seamless integration and can lead to cascading failures. [Sob10] Integrability Grade: 4 Developers must design systems with testability in mind, implement unit tests, integration tests and performance tests and use testing frameworks and tools. Clear boundaries between components and services facilitate testing by facilitating isolation. Certain practices, such as a heavy reliance on external dependencies that are difficult to mock or simulate, may not assure an efficient and testable architecture. [SAM+19] Testability Grade: 4 The architecture offers ease of development through loose coupling and modularity principles, allowing developers to work independently on individual components. Complex interdependencies, on the other hand, can make development harder. Changes or revisions to one component can 44 2.4 Software Architecture Design Approaches Ranking based on Non-Functional Requirements inadvertently impact other components, causing development and testing issues and challenges. [SAM+19] Ease of Development Grade: 4 Modifiability is accomplished in reactive architecture through the loose coupling of its components therefore modifying or updating one component does not inherently effect the other components. Exceptions may arise when a change or update to one component necessitates modifications in multiple other components due to complex dependencies or shared resources. This can result in a cascading effect of changes throughout the system, making it difficult to maintain and modify individual components without impacting the stability of the system as a whole. [DSM+17] Modifiability Grade: 4 The objective of reactive architecture is to accomplish usability through intuitive, navigable and responsive user interface design. This includes considering the requirements and preferences of end users, providing timely feedback and adapting the interface based on the user’s device or location. Still, cluttered and overwhelming user interfaces can reduce efficacy by making it difficult for users to locate and utilise desired features. Moreover, a lack of clear feedback or prompt response to user inputs can result in frustration and hinder the overall efficacy of a product. [Tov19b] Usability Grade: 4 2.4.10 Non-Functional Requirements Evaluation Matrix All QA evaluation marks are summarized in the following Table 2.11. Approach/Criteria Av ai la bi lit y Sc al ab ili ty D ep lo ya bi lit y In te gr ab ili ty Pe rfo rm an ce Te st ab ili ty Ea se of D ev el op m en t M od ifi ab ili ty U sa bi lit y Architecture Centric Design 4 4 4 4 5 3 5 3 5 Microservices Architecture 5 5 4 4 5 4 4 4 5 Cloud-native Architecture 4 5 4 4 4 3 3 4 4 Waterfall Software Dev. 3 4 3 3 3 3 2 1 4 Domain-Driven Architecture 4 4 3 3 3 3 2 3 4 Service Oriented Architecture 5 4 4 5 4 4 5 4 5 Event-Driven Architecture 5 4 3 4 3 3 4 3 5 Model-Driven Architecture 3 3 4 4 3 4 3 3 5 Reactive Architecture 5 4 4 4 4 4 4 4 4 Table 2.11: Architecture Evaluation Matrix 45 2 Literature Review 2.5 Conclusion Enterprises may use this rating to find the best software architecture design method for their dispersed development teams. The rating represents a subjective evaluation of how well each strategy satisfies the characteristics indicated as crucial in the supplementary research question and as such, each strategy has advantages and disadvantages. Businesses may make better judgments on the most appropriate software architecture design strategies by taking these rankings and the reasoning behind them into account. The final ranking of all software architecture design approaches is presented in Table 5.1 on the basis of the average score calculated from the elements involved in decision criteria. Approach Average Score Rank Microservice Architecture 4.44 1 Service Oriented Architecture 4.44 1 Architecture Centric Design 4.11 2 Reactive Architecture 4.11 2 Cloud-Native Architecture 3.89 3 Event-Driven Architecture 3.78 4 Model-Driven Architecture 3.56 5 Domain-Driven Architecture 3.11 6 Waterfall Software Dev. 2.89 7 Table 2.12: Architecture Ranking Table In conclusion, software architecture design success hinges on its ab