11.2.1 Layered Architecture Pattern

This pattern of architecture is the most commonly used pattern for the development of architecture for a software system. The model view controller (MVC) is also the structure of the layered architecture pattern. Drupal, Java EE, and Express are some examples of models of layered architecture styles or patterns. In this pattern of software architecture style, there are four layers that are led by this architectural pattern. The presentation layer contains the graphical representation and the general design of the system. Whereas, the business layer is concerned with the inclusion of models and logic for the explicit problem of a business. The application layer or database layer is processed between the presentation and business layer for the purpose of providing abstraction. Whereas, the persistence layer processes the code to access the database layer, while it also manipulates database queries and statements of the database, etc. [19]. Figure 11.1 represents the layered pattern of architecture design.

The majority of developers are more acquainted with the layered pattern of architecture than the others. This pattern also provides easy ways for writing organized and well-defined testable software applications [19]. There are also some drawbacks of this architecture pattern. This pattern of architecture leads to monolithic applications that are hard to split up.

11.2.2 Microservices Software Architecture

This architectural style or pattern is considered as an assemblage of services that are loosely coupled, independently deployable, highly maintainable, and testable, organized around business capabilities, and owned by a small team. Microservices is an architectural pattern that is used to develop services-based applications based on small, loosely coupled services. In this software architecture pattern, microservices have their own divergence responsibilities and a team can develop them autonomously like other microservices [20]. Figure 11.2 represents the graphical overview of microservices architectural style.

This layer gives accessibility to the developer for naming and arranging microservices unconnectedly. Microservices architecture is easy to scale because of the less dependent and loosely coupled services modules. There are some drawbacks of this architectural pattern. A user’s action can pass through various microservices, which is why there are more chances of failure when something is done incorrectly in the process.

11.2.3 Event-Driven Software Architecture Pattern

Event-driven architecture pattern is one of the software paradigms used for promoting the detection, production reaction to events, and consumption of events. This architectural model acts like a robotic system and activates when some events occur. An IoT software system is mainly developed using this software architecture pattern due to its artificial intelligence [21]. This software architectural model is also used for developing of those systems which directly interact with humans for the accomplishment of some specific task, etc. Figure 11.3 shows the graphical representation of an event-driven software architecture pattern.

An event-driven architecture pattern works by receiving events from the collector and gives a response accordingly. More than one event is also queued in the event queued box as shown in Figure 11.3.

11.2.4 Blackboard Software Architecture Pattern

A blackboard architecture pattern also deals with the concept of artificial intelligence. This architectural pattern is also considered as a useful pattern for the development of IoT software systems. It has components of a blackboard which act as a central repository of data [22]. This architectural pattern is often useful for those problems which have no deterministic solutions or strategies. Figure 11.4 shows a graphical representation of blackboard software architecture.

The independent components are communicated exclusively through a common global data repository, or it may be a blackboard. A heuristic problem in artificial intelligence (AI) is the basic core example of the blackboard software architecture pattern.

11.2.5 Systematic Literature Review for SADM

For the process of protocol development, especially for the software architecture designing challenges model (SADCM) for the IoT software system, we studied and analyzed many survey-based approaches in the process of collecting data for analysis. We found that the literature review (SLR) was the most specific approach for data collection, identification, and solution of research questions. Stapić et al. [23] stated that the three phases of SLR are planning, conducting, and reporting. The main focus of this study will be the planning phase. This assessment will help settle quality-related issues and challenges in the field of software architecture outsourcing. The review is totally based on the research questions [24]. After the finalization of our research questions, we will initiate the trial search on different databases and will define a type of strings. After searching the relevant information, we will also specify the inclusion-exclusion measurement for the literature and for the data extracted.

11.4.1 Constructing Search Term Formulation

The following three basic formulation phases of a search show the details of each question separately. Population, Intervention, and Outcome (PIO) [31] is a particular context-based framework used mostly by researchers to integrate and formulate research questions and to assist the literature review.

Tables 11.2, 11.3 and 11.4 express the search term construction for each question respectively.

11.4.1.2 Search Process and Practice

The planning for the SLR was conducted as:

• Definition of search terms in the process of identifying population, intervention, and outcomes.
• Identification of substitute spellings and synonyms.
• Validated key words of search terms in pertinent deducted literature.
• Use Boolean operators (AND, OR) for the guidance of search engines (if applicable) for precise search.

A trial search was performed for the identification for getting the relevant literature from different digital libraries. The following trial search was performed in different digital libraries, i.e., IEEE Xplore, ACM, SpringerLink and Google Scholar.

((“Software architecture” OR “Software Structure” OR “Software Construction”) AND (“Software outsourcing” OR “Software deployment” OR “Software utilization”) AND (“Internet of things” OR IoT) AND (challenges OR limitation OR issues) AND (Solution OR methods OR practices OR ways)).

The search string used for the final search was:

Results from IEEE & Google Scholar: ((“Software outsourcing” OR “Software deployment” OR “Software utilization”) AND (“Software architecture” OR “Software construction” OR “Software structure”) AND (“internet of things” OR IoT) AND (vendor OR developer) AND (challenges OR issues OR limitations OR barriers) AND (Solution OR Recommendation)).

By applying the final search string, we found the following list of research articles in the different digital libraries shown in Table 11.5.

We got low data in the final selection, thus we decided to perform the snowballing technique for the final selection chapter in order to enhance the quality of our research. Adi Bhat [32] stated in his article that snowballing is a referral chain sampling which is defined as a nonprobability sampling technique in which the samples have qualities that are rare to find. This is a sampling procedure in which the existing subjects provide referrals to convert the samples required for a specific research study. After applying successful snowballing, we received the results shown in Table 11.6.

The snowballing technique enhanced our results from 55 chapters to 110 chapters, so it has been considered valid for further review to be adopted.

11.4.2 Publication Selection Process

In this section of our research, the task to be carried out is of inclusion and exclusion of raw and useful data from the collected materials/data. We will include only those data of research publications which are relevant to our research questions aim of vendor outsourcing for the software architecture designing challenges model for IoT software development.

11.4.3 Quality Assessment of the Publication

The quality of each publication will be determined by quality analysis and assessment. The criteria for publication selection would purely be based on the following conditions:

• The authors of those publications must identify the challenges and limitations in software architecture outsourcing.
• Which practices will be handled and would be carried on for resolving the challenges faced by the vendor in the software architecture model design?

11.4.4 Data Extraction

11.4.5 Data Extraction Demonstration

The data which are preserved through primary and secondary studies on the allotted string are expressed in the format shown in Table 11.7.

11.4.6 Findings

List of Challenges Found Through Systematic Literature Review (SLR): With the help of SLR, we found various issues/challenges faced by the development team, i.e., vendor-side organization, during the development of software. Two issues were noted as the most critical during our search, as they possess high frequency. The first was the “lack of common development” issue, with a frequency index of 61%. The “lack of common development” is further proposed by the group of following challenges: “structuring issues,” “software complexity issues,” “requirement issues,” “diagram formalization issues,” “module design,” moved later in the development process. In 1972, Bengtsson [33] claimed that the way a software system disintegrates into modules affects its capabilities to meet levels of efficiency in certain aspects, e.g. performance, flexibility. Software architecture is concerned with which modules are to be used to develop a system and how these modules are related, i.e., the full structure of the system. The architecture of a software system sets the boundaries for its quality. Hence, to design the software architecture and to meet the quality requirements is to reduce the risk of not achieving the required quality levels. The design team vendor organization partaking in a deep level of situational consciousness in the beginning can also gather relevant information to be adopted and interpret it from different viewpoints of the involved stakeholders, exchange (well-grounded and reasonable) locations based on expectations, assumptions and predictions over the excellence of the resulting architecture with a client, and ultimately agree upon a single decision that will be interpreted later on [34].

The second most critical challenge found with the help of SLR is “lack of poor architecture,” with a frequency index of 56%. Rick Kazman, a professor at the University of Hawaii, raised the well-known observation of John Zachman in his article about architecture that “architecture is architecture is architecture,” which means that in all possibilities the system could be laid down by its scaled architecture [35]. Johan den Haan stated in his article [36] that the explanation of the term “designing” is required for making a distinction between the architecture and the design of a system. These terms refer to how systems will be constructed. According to [36], there are two different system notions present, the ontological and the teleological system notions. The teleological system notion refers to the function and the (external) performance of a system. This notion can be imagined with a black-box model. The teleological system notion is satisfactory for controlling or using a system. The ontological system notion, on the other hand, can also be used for changing or building a system. It is about the operation and the construction of a system and can be modeled with a white-box model. Our findings are presented in Table 11.8, which can facilitate the development team and the clients in overcoming the issue found with the help of SLR.

The third most important challenge found with the help of SLR is “lack of reliability,” which is also considered a significant challenge. The said challenge is fixed with the frequency index of 41.8% as shown in Table 11.8. In his article, Eoin Woods [37] stated that every system is treated according to its reliability. This means that the software architecture should be concerned with enabling evaluation of the developed system.

The fourth and fifth challenges identified with the help of SLR for the development of the framework for software architecture designing challenges model for the IoT are recorded as “lack of development limitation,” and “lack of management issues,” with frequency indices of 36.0%. Both challenges were placed at the same number of frequency index due to their relevancy. Bernardo et al. [38] and Rubrich [39] specified the pivotal role that management plays at the beginning of every task or exercise. They further stated that the lack of management issues include ill-scheduled, unrevealed deliverance and period, unrecognized prices and checklists, and undefined goals, etc. They also emphasized that in software development outsourcing, the parties should adopt the proper checklist of arrangements. Without proper management, the workflow would be faced with failure ahead after the commencement of its utilization by the end user.

The sixth and seventh challenges of the software architecture designing challenges model are “lack of environment issues,” with a frequency index of 34%, and “cost issues,” with a frequency index of 33.6%. According to the statement of López et al. [40]. The IoT’s products and life cycle are important and interoperable for the proposed architecture of software development for IoT software systems. Thus, due to the costly products for the development of an architecture for the IoT software system and the lack of consent from both the parties, i.e., vendor- and client-side organizations, difficulties may be created in outsourcing, which is also known as the failure of unsuccessful software outsourcing. Another important factor influencing the workflow of any software architecture are environmental issues, i.e., without having a proper environment for the development of an architecture for the IoT software system, the correspondence between client- and vendor-side organizations will also be affected. Yvnnx [41] also stated that lack of environmental awareness results in problems in the environment, such as loss of biodiversity, pollution and global warming, etc., which can also affect the flow of outsourcing during the development of software architecture for the IoT software system.

“Lack of technology” is the eighth challenge in Table 11.8 of the software architecture designing challenges model; it maintained the frequency index of 29.0%. Soto and his team [42] discuss the development of software architecture and state that the end-user being unfamiliar with the system they are interacting with and the nontechnical equipment used during the interaction, can also lead to system failure. The lack of technology refers to the improper equipment from the vendor-side organization used for the development of software architecture. As technology nowadays plays a significant role in making the daily lives of humans easier, “lack of knowledge for high skilled resources,” with a frequency index of 28.2%, is known as the ninth uppermost challenge for the development of the software architecture designing challenges model for IoT software systems [43].

A system which doesn’t have specific privacy would also be faced with failure due to the damage caused by lost data. Here, the “lack of privacy,” with a frequency index of 28.0%, is considered as the tenth challenge for the designing software architecture model for the IoT software system. This refers to the highly automated, entirely automated, or even autonomous robot systems or vehicles with earlier unavailable intelligent capabilities requiring new techniques of architecture and development methods to grasp the highest mandatory stages of safety and security [44].

The eleventh and twelfth ranked challenges for the software architecture designing challenges model for the IoT software system are “traditional co-located models,” with a frequency index of 27.3%, and “lack of assessment issues,” with a frequency index of 27%. The traditional co-located model refers to the previous concept of model development and designing which are acting or performing the same task in different shapes and physical faces adapted by the developed system for a particular task [45]. Whereas, the lack of software assessment is the progression assessment, which is a self-controlled inspection of the software processes assumed or used by a company or organization, based on a development model. Our further investigation showed that the software assessment quality and structure is influenced by its development perspective, which is affected by the customer contribution, agility, which allows cooperation among the development teams; outsourcing; and human influences, i.e., innovation, developers’ creativity, art and experience, which are not partial to development approaches but customer claim and feedback systems [46].

“Lack of poor scheduling” is also framed as a 13th challenge for the software architecture designing challenges model for the IoT software system. Earlier negotiations on the fixation of origins and other essential services of a system are also based on the successful system. The poor scheduling challenge also refers to the consequences of poor management scheduling, which is generally seen in the form of stress in the workplace, staff conflicts, time distribution, poor productivity, ultimately poor retention of trained workforce, and increased absenteeism. We mainly focus on the lack of poor scheduling and a random mixture of resource requests for interactive and batch applications in an architecture-independent state or procedure, etc.

The fourteenth, fifteenth, sixteenth, seventeenth, and eighteenth challenges have the same frequency, with only 25% from the extracted data of the literature review. These challenges are “lack of trust,” “‘communication workflow,” “market expansion growth,” “framework integration,” and “lack of effectiveness.” The lack of trust is a common challenge faced by software architecture vendor organizations. Some empirical insights of software practitioners on the role of trust in software outsourcing relationships are when the customer expectations are high, deliverance time is limited, and the other essential resources are found limited, then the vendor organization should ensure the arrangement of the essential services on time for the successful trustworthiness with the client-side organization [47]. Our literature study has also identified another challenge named “lack of communication workflow,” as the source of failure of software development outsourcing. It means that the meager communication capabilities may be separated as the lack of proper language, accent, or slang while one speaks. It can be boosted by unfailing practice and wrought out by refining our soft communication skills [48]. The sixteenth challenge of our explorative study is “market expansion growth.” It means suggesting the flow of a service or product to a broader section of a current market or into a new demographic, psychographic or geographic market. Instead, software architectures must be thoroughly designed and then executed using fragmentary growth, which suggests that software architects need to incrementally and iteratively refine, assess, and improve a software system [49].

The seventeenth challenge of the study is “framework integration issues.” This issue of designing a software architecture involves integration frameworks that deliver a model for statement and interaction between mutually interconnecting software applications in service-oriented architecture (SOA). The management plan is comprised because the plan used by the organization is to achieve goals. As we have already stated, the IoT is trending in the market, so there will be more customer requests. The influence of the IoT on software development is yet to be known; as a part of this research we have composed software development models [50]. The eighteenth challenge of our research investigation is “lack of effectiveness.” The maintenance and restoration of software design and architecture are often defenseless against rapid increases in size and complexity, changing requirements, and insufficient understanding of the required architectural design [51-55].

The nineteenth and twentieth challenges of our study are “fault tolerance,” with a frequency index of 17.3%, and “deliverance issues,” with a frequency index of 15.5%. Both challenges were considered as dropped from our research, investigation and analysis, as our critical percentage for each challenge was 25% and > 25%.