Analytical Evaluation of SOA and SCRUM Business Process Management Approaches for IoT-Based Services Development

e SCRUM approach and Service-Oriented Architecture (SOA) framework are critical in assessing the factors that inuence the eciency of a business process and ensuring that business objectives are fullled, and the process is on track to meet those objectives. Flexibility and change adoption are critical features for both SCRUM and SOA approaches. Even though both sides encourage agility, the integration of the two independent concepts (SOA is the architectural framework while SCRUM is the development process) should be considered before being used in software management and development projects. is study assessed and analyzed both SCRUM and SOA’s diverse and dierent software architectural frameworks and development methodologies as well as their environment, which is integrated with the context of software project management and development setup for the software development industry. In addition, this study explores the similarities between the SCRUM process model and the SOA architectural framework to see if they are compatible and, if so, how they may be combined to enhance SOA-based projects. is research also looks at how to build and use a SCRUM methodology for large-scale SOA projects. As a result, SCRUM was chosen as the software development methodology for a research and development project based on SOA. In terms of project development and implementation, the complete project structure is made up of eight main parts.


Introduction
It is essential to the success of any organization in today's modern, dynamic world for them to be able to welcome, and adapt to, change smoothly and e ciently. SOA is a design method for constructing, developing, managing, and deploying software applications and infrastructure in which all applications are arranged into network-accessible and executable business services [1]. SOA and agile software development approaches necessitate exibility and change acceptance. It is recommended to thoroughly investigate (before implementing the architecture framework and development process in a software development project) the integration of these two concepts [2] [Dias, 2022 #232]. As a result, using an e ective agile approach for SOA-based application development, it is critical to have a system in place that allows for substantial needs changes that occur even during application development while preserving software superiority and quality [3]. e client's requirements are enhanced and predictability is improved by prioritizing iterations and user stories in accordance with agile principles [4]. ASD (agile software development) involves the rapid and e cient development of products through frequent and complete releases that allow their members and sponsors to assess them before they are released [5,6]. Agile retrospective meetings are used to examine and test the application and process. In this manner, a mockup is transformed into an iterative and incremental approach, a functioning progressive and creative system in which stakeholders provide feedback based on frequent software releases.
Iteration emphasizes the delivery of working software that is of high quality and value to both clients and the project. Besides creating useful artifacts, it also generates others that are bene cial to both the user and the project. Agile processes are designed to deliver high-quality functional deliverables in a timely manner. e main purpose of an agile process is not to focus on designing models and documentation but rather to deliver products and deliver them as quickly and efficiently as possible [7,8]. SCRUM is one of the agile approaches that, because of its flexibility and straightforwardness, has become a common way of introducing agility [9]. In the business world, it is a well-known agile management technique. Due to the diverse nature of group members and their surroundings, agile application development in an enterprise setting can be complex [10]. By promoting both people and groups, the SCRUM process assists in the discovery of better ways to develop software [11]. With SCRUM, the development process is broken down into sprints in order to focus on delivering a useful product and a project that benefits everyone [12].
SCRUM is the most frequently used agile methodology, stresses group self-management, empirical feedback, and the goal of rapidly improving completely high-quality products [13].
e key shareholders in SCRUM are the product owner, often known as the client, the SCRUM team, and the SCRUM master. e project manager's tasks are shared among these three SCRUM roles [14]. e SCRUM master's job is to make sure that the software development team's process goes well by facilitating SCRUM meetings and ensuring that all SCRUM rules and ideas are adhered to. e SCRUM team is a cross-functional group with specific expertise. Sprint planning meetings are held at the start of each sprint cycle. e product owner and SCRUM team decide on the sprint target, as well as which and what the sprint will strive to accomplish, at this meeting. During the sprint review meeting, the success of the sprint will be measured against its goal. Each sprint ends with a sprint review meeting, during which the team displays everything they have completed. Members of the team discussed how they collaborate, interact, deal with behavioral challenges, and improve their technical abilities. erefore, among other things, the following sprint is faster at the sprint retrospective meeting [15].
SCRUM is a black-box methodology for building and finding a project's team and processes while working on it. White box process models like the waterfall model are nonagile methodology from a management viewpoint [14]. e sprint's objectives and outcomes are defined during the planning and postmortem phases. Careful preparation is necessary to overcome any growth hurdles in every step or process. Retrospective meetings, also known as postmortems in agile, are necessary for examining operations and establishing a best practices knowledge base. Figure 1 illustrates the properties of process models on a white box and black-box basis.
Nonagile development methods are a time-consuming procedure for creating software. ese methods are based on a series of iterations that include identifying requirements, structuring solutions, testing, and deploying them. Traditional procedures involve a lot of documentation at the outset of a project and provide a preset set of requirements.
ere are many traditional approaches, such as the Waterfall, Spiral model, Win-Win, and Unified Process. A precise upfront strategy, extensive documentation, and a large-scale upfront design are all required for heavy-weight processes. Nonagile development methods are a time-consuming procedure for creating software. ese methods are constructed through a series of iterations that include establishing requirements, structuring solutions, testing, and deploying them. Traditional procedures involve a lot of documentation at the outset of a project and provide a preset set of requirements. e Spiral model, Waterfall, Win-Win Spiral model, and Unified Process are examples of traditional approaches. A precise upfront strategy, extensive documentation, and a large-scale upfront design are all required for heavy-weight processes. Large-scale projects with a well-defined and relatively consistent set of needs benefit from traditional methodologies. However, some practitioners have begun to employ agile approaches for specific projects [16].
SOA is a design, development, management, and deployment framework and strategy for software applications. It is a software architecture within which applications are grouped into services, each with network-executable and accessible business rules. SOA is also defined as a combination of applications, clients, and existing systems that can instantly respond to changes in those systems [13]. SOA is often considered a candidate for the most effective methods for developing distributed applications. Instead of starting from scratch, SOA allows you to reuse the functionality of existing systems. In SOA-based systems, this property of reusability boosts organizational economic benefits [14]. Each SOA service is self-contained, but not isolated from the rest of the system. In the problem domain, each service encapsulates a specific logic. In addition to loose coupling, service contracts, autonomy, abstraction, discoverability, and statelessness, SOA has a number of other properties that makes it a powerful structure [17].
Even though SOA and agile methodologies are usually associated with similar concerns, there is still no clear description of how to organize and set up both of these methodologies in one platform for IoT. ere is very little information on how this integrated implementation would affect crucial criteria like quality, productivity, agility, and innovativeness.
According to the following statements and actual market needs, the following study examines the similarities between the SCRUM process and the SOA architecture framework to determine if SCRUM and SOA are compatible. is research also looks at how to build and use a SCRUM methodology for large-scale SOA projects. As a result, SCRUM was chosen as the software development methodology for a research and development project based on SOA. e entire project structure is comprised of eight basic modules in the project development and deployment perspective.
is research is classified into seven different sections. e current section introduces the many important concepts employed in this research. e second stage discusses existing research on SCRUM and SOA techniques, as well as their interpretation based on analysis. e research design and setup, as well as the analysis of SOA, SCRUM, and the joint use of SCRUM and SOA, are all covered in the third 2 Scientific Programming step. e integration analysis is offered in the fourth step, the discussion of SOA and SCRUM integration is presented in the fifth section, and the 6th and 7th steps, respectively, present the entire research's conclusion and recommendation.

Literature Study
Agile techniques are designed to ensure that software products are developed quickly and efficiently. Working in iterations [9] makes this possible. As part of an iterative process, working software is delivered to both the project and the customer. During iterations, software and other artifacts are created that benefit the client and project in the same way they benefit the client [9]. Agile processes are primarily concerned with dynamically delivering deliverables and working products, rather than focusing on design models and documentation [7]. When constructing sophisticated and huge software, traditional development experts agree that skipping the paperwork and evaluation process leads to corporate loss of memory. Agile experts, on the other hand, agree that applying agility to software building and worldwide software release has resulted in better results in reaching the required outcomes [18,19]. It will be difficult for organizations to coordinate and integrate agility with worldwide service provision, but it will also allow them to provide business software that is fast and error-free [20].
Agile software building strategies were created in response to a need from the business sector for lighter, faster, and additional flexible software building methods [21]. As a result, agile building approaches are focused on agility, speed, and willingness to develop [22]. Agile processes, according to the Oxford dictionary, emphasize the importance of being agile, as well as willingness to move, nimbleness, activity, and dexterity in motion [12]. Client satisfaction can be obtained as a result of the lightness of concern procedures, according to several agile approaches such as extreme programming and SCRUM [12].
SCRUM is a popular agile management methodology. ree previous surveys of SCRUM adoption have revealed a focus on actual review, group awareness, and the effort to develop and validate appropriate product increments during a small cycle [23,24]. SCRUM is a widely used agile approach in the industry, and it is the most common method of bringing agility because of its flexibility and simplicity. By encouraging both individuals and teamwork, the agile software development method supports better software development [11]. Agile processes are designed to ensure that software products are developed quickly and efficiently.  Scientific Programming SOA admits to the integration of programs, clients, and current systems into a versatile framework capable of quickly adapting system changes when they are required [14]. SOA is recognized as one of the most effective ways of developing distributed applications [25]. Instead of starting from scratch, SOA allows you to reuse the functionality of existing systems [26]. In SOA-based systems, the attribute of reusability boosts the organization's economic benefits. SOA services are self-contained, yet they are not separated from the rest of the system. In the problem domain, each service encapsulates a specific logic. e primary characteristics of SOA are reusability, loose coupling, service contracts, independence, transparency, search-ability, and statelessness [27].
Researchers and experts are mixed on whether the two approaches are similar and compatible. Critics point out the disparities between SOA and agile methodologies, claiming SOA and agile are moving in opposite directions: SOA is a framework, and agile is a technique [24,25]. In general, SOAs are top-down approaches, whereas agile is a bottomup approach [28,29]. A process paradigm such as agile works at the level of practices, whereas SOA functions at an architectural level [30]. In order to integrate SOA and agile strategies for service creation, advocates of SOA and agile integration argue that the SOA architecture and the guiding principles of agile approaches are complementary [31,32]. Some experts believe that SOA-based systems are not created like traditional ones [21].
ere are several obstacles to overcome, including stakeholder involvement, alignment between the IT and business sectors, and asset reuse. Agility and service orientation are better related to tackling such challenges [33,34]. SOA and SCRUM share many characteristics when it comes to issues like business understanding, new ways of working, and change responsiveness [35].
When evaluating and specifying SOA and SCRUM, technology challenges, as well as their ties to IT-related business organizations [36] and consumers of personal information, must be taken into account. Other requirements, such as usability and flexibility, are expressed as measurable and designable system characteristics [37,38].

Process Set Up of SOA and SCRUM Approaches
SCRUM as a developmental methodology and SOA as a platform for architecture both address comparable issues, such as flexibility and quick responsiveness to change while maintaining a strong business focus. Even though this inherent operational resemblance is clear, there has not been enough research done to determine the best strategy for integrating these two methods to reap the benefits in combination [39,40]. ere is also a need to look into the consequence of adopting SOA in terms of increasing productivity and making better use of time and resources while using the SCRUM approach. For analyzing this scenario, a case study using the SCRUM model has been chosen to build SOA-based software applications. M4S is a software application (Mining, Mapping, Modeling, and Management System) for mining resources. e overall project structure is comprised of eight main parts relevant to project development and implementation. e system is built through a series of iterations, which are discussed in the sections below. e research's effectiveness is measured by identifying, determining, and implementing one of the most effective software engineering combinations: SOA-based architecture, highly effective open-source architectures and solutions, agile development processes, and client and cloud application deployment.
A structured agile approach called SCRUM was applied to develop and refine functional prototypes in an iteration as requirements changed [41,42]. e case study system components are built with SOA to ensure that they can be used as stand-alone modules via a service gateway.
is system's architecture contains aspects of interpersonal connection, sustainability, and service dependability in the natural resource, mapping, simulation, and system management (M4S) stages, as well as the delivery stage.
Cloud infrastructure and distributed computing are used to meet these deployment needs.
e developed application's modules are developed to function like services that are interconnected that may be utilized alone and reassembled with additional modules to create a coherent system. Mineral and resource data banks, as well as applications to manage those databanks, are built expressly for the M4S system. ey were developed for open-source use as databanks, libraries, and programs.
SCRUM approaches are utilized to guarantee that the transparent process of M4S evaluates and developed, as well as stakeholder involvement and dynamic interaction between the project's various components. As a result of the adoption of open-source methodologies for engineering and project governance, academics, government, and enterprises have formed a multilateral interface to address a range of partners.
[ICT R&D program called M4S: https://www.openm4s. org], as addressed in [ICT R&D program entitled M4S: https://www.openm4s.org].org] Figure 2 depicts the M4S basic infrastructure, which includes open-source libraries, services, hosts, programs, a DBMS, and free software business resource management. Interoperability and open standards are the foundation of client-server architecture and browser-based clients. Within the planned M4S, the graphic also illustrates the components and information flow. e development of modules is managed and organized using the SCRUM-driven agile software development process [15]. e following section explains how SCRUM was implemented in this case study, as well as the responsibilities and team structure that were assigned: the procedure is set up by agile SCRUM specifications. e roles that exist and work in the SCRUM process are briefly summarized below.
(a) SCRUM Master is responsible for leading SCRUM meetings, maintaining team processes, and ensuring that the process complies with all SCRUM principles [43,44]. (b) SCRUM Coach facilitates meetings, assists teams in reaching consensus, and ensures that the development environment and team are of high quality. 4 Scientific Programming (c) SCRUM Team make up of developers, testers, architects, and analysts, which is a cross-functional team. is group is in control of the overall project's outputs and is actively involved in its building. e group is in charge of developing characteristics that meet excellence and functionality standards [45].   M4S' architectural framework, as well as the context in which the requirements and features are used. ey were responsible for business analysis and quality assurance, as well as sprint cycle management. e following are the main duties and tasks of each project participant: Project director (PD) duties are formulation, supervision, and administration of projects.
Co-PD (co-project director) was in charge of coordinating and controlling project operations, as well as maintaining interaction with public and industry partners.
Software and Computer Systems Experts were in charge of supervising system design and performance assessment.
Engineering Management Expert was in duty of overseeing project governance and quality assurance.
Team Leads were in charge of arranging and carrying out design, implementation, and delivery activities.
Unit implementation, debugging, validation, and reporting were the job of developer teams.
Co-project director's duties are handling interaction and collaboration with public and commercial partners.
Part-time Mining and Software Experts are on duty of verifying and confirming M4S and its modules.
Advisers (student monitors) were on the duty of monitoring and advising UG/PG students who were studying on M4S projects.
Part-time programmers were on the duty of module building, debugging, and verification.
Interns worked on different components of M4S projects as a research and implemented and documented the tasks they were allocated. Figure 4 illustrates the M4S project's work breakdown structure (WBS), as well as the relevant individuals for each block of activity.
Below is a description of the SCRUM method and its many aspects as they apply to the project.

User Stories.
A client story encapsulates the user's goals for using the system. From the client's perspective, this goal is converted into a user story [46]. e product owners (project director and codirector) design an approval test card based on the user stories, and the engineers build those stories. e approval test card consists of a series of test instances that are used to evaluate the completed client stories. Only when the approval tests pass will a user story be declared successful. e user stories are then converted into system characteristics [17]. A characteristic is a unit of functionality that has to be incorporated in the system or "task that a character is a unit of functionality that has to be incorporated in the system" or "task that requires to be performed".
Individual features are divided into smaller units in the M4S project. en, for each specific assignment, story cards are constructed. e average working day was eight hours   6 Scientific Programming daily, and the completion time for tasks was between five and fifteen days. Each story card is usually worked on by one or two members of the team at a time. Assignments are prioritized according to their importance. Each member of the team decides which stories to complete first. Figure 5 illustrates two stories that are performed until the next narrative is picked.

Sprint.
According to the SCRUM process, programming is split over 2 or four-week sprints. Sprints are periodic iterations of development that consist of specific tasks completed [36]. At the beginning of every sprint, throughout a sprint discussion session, tasks are assigned to sprints based on the backlog status. Creating the M4S project should also be preceded by a one-week sprint (named sprint 0). is gives the programmers more freedom to learn about the working platform, scientific solutions, and reusable materials.
In seven sprints, M4S's initial module has been finalized. 1st sprint comprises nine stories, seven of which were finalized inside the sprint time frame and the final two stories were added to the 2nd sprint that will be finished later. Every sprint is documented in an MS Excel file that comprises all of the details about each story, including the team members who worked on it, the amount of time it will take to complete it, and so on. e initial sprint is visualized in Table 2 as an example.
As part of the SCRUM process, the product owner, team, third parties, and SCRUM master meet regularly to address issues that have arisen during the process. e gatherings take place to guarantee that the project runs smoothly and that the overall quality phases of the produced system are preserved and maintained. Every day SCRUM meetings, sprint retrospective meetings, assessment meetings for sprints, meetings to plan sprints, and sprint release meetings are all part of the SCRUM process paradigm. Such 5 meetings are conducted and monitored throughout the M4S deployment process in various scenarios. e following subsections go over each of these meetings one by one: (1) Meeting to Plan the Sprint.
ere will be 7 sprint sessions to make a work plan that would be completed in a sprint. Every two weeks, a session is usually conducted.
e Project Owner and the SCRUM Group (M4S project director and codirector) identify the sprint objectives during this meeting. At the sprint evaluation session, the sprint's success is assessed. e product owner prioritizes the story cards, which means he or she describes the most important story point to the SCRUM team. Finally, the SCRUM Team must create a sprint plan and sprint backlog   8 Scientific Programming that specify how long it will take to complete the assigned work [47].
(2) SCRUM Each Day. ere is a regular SCRUM session with the primary goal of ensuring that the application's features are implemented in the sequence in which they were planned. is meeting usually takes place at the start of each sprint and lasts between 20 and 35 min. ese meetings will be conducted at the allotted hour. During this meeting, each team member will respond to the following three questions, such as: (i) How much and what kind of work have you performed until yesterday? (ii) What are your work objectives regarding today? (iii) What are the hurdles that would restrict you from achieving the objective?
If an issue comes, it is the role of the team manager (officially known as the SCRUM team) to simplify and tackle the issues. Unsettled problems are highlighted again at a later meeting. is meeting will take place in the same venue, at the same time, and for the same length of time as the previous one.
(3) Sprint Review Meeting. After each sprint, there is a session arranged. Participants of the team present what they have achieved and accomplished during the finished sprint during this session. Typically, this meeting takes the shape of a demo of newly invented features. A majority of the sprint goals were met by the M4S SCRUM team, and 95% of the backlog items were fetched for the sprint, as well as the majority of the product backlog items. As a result, 98% of the elements of a project like M4S meet the "performed" standard, are approved, and have a "done" label. e leftover 2 percent of elements not implemented at the sprint are planned for upcoming sprints. e elements were closed whenever the project manager (product owner) is satisfied with the 98% delivery record, and the next backlog is modified to highlight the features that require additional implementation. (4) Retrospective on the Sprint. Members of the M4S team went over the approach team's procedures, interrelate, behavioral characteristics, refining methodological skills, etc. during this meeting. e team leader (SCRUM Master) and team members discussed three things during the SCRUM meeting: what went well, what did not go well, and what improvements can be made at the next sprint. e team's all performance (in the form of metrics) is assessed, and methods for growth (within the shape of KPIs) are highlighted, as already explained in our earlier research paper. It is also recommended that members of the team exchange technical skills and knowledge and that they maintain constant communication with the product owner, among other things. is meeting takes place after each sprint and lasts about 2 and 3 hours.
(5) Planning for Release. In a release backlog, a release strategy meeting is a method of defining, prioritizing, and separating software features in an ongoing and undisturbed way.
is entails identifying and committing to the following: (a) Release goals (b) Prioritized set of user stories (features to be developed) (c) Rough estimates of user stories (d) A release dates e following are the primary input steps in the M4S project that are held during this meeting: (a) e user stories are evaluated by the members of the team, i.e., making intelligent guesses on the story's size. (b) Find your sprint velocity, that is, the amount of story points you finish in a sprint; you can find more information in our previous article. (c) Use the forecast to calculate story points that will be finished as part of a date-based release (velocity x number of sprints). (Total story points * velocity) sprints are expected to be needed to complete performance-based releases.
Story points (calculated above) are used to select the most important stories. A functionality-based release will be selected if all of the stories will be completed by the expected completion date (calculated above).

Integration of SOA and SCRUM
In this section, we will explore how SCRUM, a process for developing software, and SOA, an architectural style, interact. An SOA architecture provides an organized and welldefined technology architecture that incorporates notions of agility and design patterns to enable quality, efficiency, and productivity. To construct flexible and adaptive systems, service reusability and abstraction [16] are employed. By building new services and modifying existing ones on top of our underlying architecture, SOA enables agility at the design level rather than modifying the architecture. SCRUM enables incremental development and quicker client feedback. SCRUM facilitates incremental development by allowing customers and the development team to provide Scientific Programming 9 feedback more quickly. SCRUM and SOA both help companies construct business and development strategies that are aligned. e M4S project development environment uses concepts that are similar to the SCRUM and SOA processes to reach the common goal of developing necessary software. e SOA can still take advantage of agile SCRUM while operating in a well-managed environment with no undesirable overlap. A clear strategy for bringing change in modest steps, on the other hand, should be devised.
SCRUM can also be used for traditional software or designs by specifying needs in a backlog and providing customers with incremental outcomes. Nonetheless, additional development expenditures and overall project costs are projected [48].
When it comes to cost-effectiveness and responsiveness, IT organizational design plays a crucial role in helping agile to achieve the claimed benefits. Otherwise, the agile approach may only provide a minor value to the organization.
SOA and SCRUM, as previously said, are two techniques that pursue different paths. SCRUM is a bottom-up approach to process development (begins with basic design and ends with prototype delivery). Services are developed based on the SOA system (a top-down approach). Does the question arise as to how these various methodologies are compatible with one another when used in a development process? Another debate is if SOA follows the agile approach in the same way as SCRUM does? If the answer is yes, how should you proceed? Finally, how might these two approaches be combined to maximize the benefits afforded by each separately? is section addresses these concerns, as well as the similarities between SOA and SCRUM metrics. Figure 6 illustrates the standard SOA and SCRUM development paradigm. Table 2 shows the most essential SOA and SCRUM metrics that can help enterprises and consumers who want to employ SOA and SCRUM combined in a software engineering project (Table 3).
Some SCRUM and SOA metrics have been combined to be used in both SCRUM and SOA environments. ese metrics integrate SCRUM and SOA metrics, which have similar goals but differ in terminology. e development process can be expedited when these KPIs are appropriately measured, resulting in enhanced business agility, adaptability, and compatibility for SOA and SCRUM settings.
Ratio measurement of completed stories versus planned stories in SCRUM and percentage measurement of new services versus total services in SOA evaluate product performance using ratios and percentages. ey are both measuring service and work, but they are utilizing distinct terminology. Team velocity, development time, and average development time are three metrics that the team uses to track its progress and the time needed to complete a service.
is metric can be combined with team velocity measurements, which can be used as an integration measurement for SOA and SCRUM. Since SCRUM and SOA use different metrics for assessing quality, but their intent is the same, both of these metrics can be used as quality assurance metrics to gauge the quality of services under a SCRUM model.
Are team members ready to work when it comes to the team enthusiasm metric? Members of the free-planned architecture team will work gladly and obey all laws and rules if they are satisfied and are working in a pleasant environment. ey will collaborate in a team setting. When team members are working eagerly since they are happy, communication between them will always be pleasant.

SCRUM and SOA Compatibility Discussion
e major goal of SOA and SCRUM is to make the entire organization agile by utilizing services like software application building blocks [49]. Also, using the SCRUM process paradigm to develop software involves increasing organizational agility by combining SCRUM principles that can improve collaboration, communication, and feedback [13,14]. Although there are some similarities and incompatibilities between SCRUM and SOA, as previously noted, there are certain distinctions and incompatibilities between the two techniques To design a framework for their integration, the compatibility and commonality of these two development approaches are investigated [50,51].

Compatibility of SCRUM and SOA.
It may be unclear why commonality and compatibilities between SCRUM and SOA are required. e two concepts (process and architectural style) are completely separate from one another. Although most SOA teams are subconsciously aware of how services are planned and developed, identifying compatibilities of both when used together is sensible and valuable. e focus is entirely on policies related to service design. SOA, like SCRUM, stimulates certain team composition and communication patterns among teams based on policies [3]. SCRUM is similar to human hands working using gloves, whereas SOA is similar to that glove. e majority of SCRUM and SOA principles are thought to be compatible because they are both adaptable approaches [52]. Although SOA that utilizes a traditional method, for example, waterfall design, turns predictive, predictive techniques depend mainly on requirement assessment and careful scheduling at the beginning of every cycle. Any change which has to be made will be subjected to a comprehensive modification monitoring and prioritization procedure. An agile methodology employs an adaptive technique in which no extensive preparation is done but only specific upcoming jobs associated with the features which must be achieved are assigned. e squad responds to changing product needs regularly. e product is thoroughly evaluated on the regular basis, reducing the possibility of serious errors mostly in the future. e strength of the agile approach is customer interaction, and the agile manufacturing setting is characterized by open dialogue and minimal paperwork. Teams work closely together and are frequently based in the same geographical area. As a result, in the creation of SOA projects, an agile paradigm is best suitable for the quick implementation of adaptable services [53]. SCRUM application implementation would be ineffective lacking a solid understanding of the organization's goals. Absent a clear 10 Scientific Programming picture about how to develop and create utilizing SCRUM process concept guidelines, SOA is a loss of time and money. Because it emphasizes the capacity to react with modifications, the adoption of SOA as a widespread technique for designing software apps is also on the growth. Because SOA development and agile development both need adjusting to changes, it appears that utilizing the agile approach to build SOA apps is a logical fit. us SCRUM and SOA are both regarding agility, and they may be utilized combined by adopting a series of principles and ideas that are not mutually exclusive. In this manner, they keep each other in balance [54].

SCRUM and SOA
Commonalities. SOA appears to be an architectural method that highlights the necessity for commercial organizations to be intelligent and capable of responding to rapid commercial changes, as previously indicated. e goal of reusing software is indefinable; developing services can assist in reaching that goal. Teams build services as a result of the SOA method that can then be combined into applications [48,55]. A SCRUM process emphasizes change response in application development [56]. Teams can help enterprises become more agile by incorporating both technological and nontechnical approaches. SCRUM and SOA are complementary and have similar goals. Change is flexible in both circumstances, and companies must be able to deal with it successfully. As a result, SCRUM might be a viable option for developing SOA-based apps.

SOA and SCRUM Adversity.
Whereas SCRUM and SOA seem to be compatible, there are some significant differences between the two methodologies which should be acknowledged and managed when using SOA and SCRUM in the same project [57]. One of the main reasons is that the two techniques originate from different directions and go in opposite directions. SCRUM has typically been used for small projects, but as processes have improved and practitioners have gained knowledge and experience, the SCRUM manifesto's standards could now be used for massive software projects. e SOA approach to application development is top-down and divide-and-conquer [4]. e "divide" part of the approach inevitably leads to a lack of communication across teams. ere seem to be three primary areas wherein SCRUM and SOA are in conflict with one another.
(1) SOA promotes architecture to be upfront; however, the SCRUM community does not encourage upfront design and considers Big Design Upfront (BDUF) to be an antipattern. (2) SOA promotes teams to be divided along functional lines, whereas agile supports the formation of crossfunctional teams. (3) SOA lacks formal feedback and communication within development teams, whereas agile emphasizes frequent assessment on both technical and personal levels.
It can be difficult to make changes when employing SOA in a large setup [53]. Other difficulties, such as a lack of team communication and service discoverability, may exist in addition to software agility and cost. Rather, we should strive for robust collaboration and transparency. Every team will  Scientific Programming commit an easily customizable version of their service available for internal testing. Test data will be segregated from service by the service team so that it can continue to function even if the code is corrupted. e customer care team will advise clear and straightforward instructions for adding additional calls to the service stub.

Conclusion
Instead of starting from scratch, service-oriented architecture (SOA) allows you to reuse the functionality of existing systems.
is reusability attribute in SOA-based systems enhances financial benefits for companies. In contrast, the SCRUM process model focuses on cycle and customer feedback to increase functionality while also enabling for predictability of evolving requirements.
is study establishes a baseline for finding commonalities and compatibilities between SCRUM and SOA processes to ensure the most effective use of the structured SCRUM management process in SOA-based application development.
e majority of SCRUM and SOA rules are not mutually incompatible, according to this research. Neither SCRUM nor SOA is mutually exclusive. ey both leverage rules and principles that apply to agility. Using formal KPIs based on specific SCRUM and SOA indicators, it is possible to determine the success of a combined SCRUM and SOA development environment. All organizations that wish to apply SCRUM and SOA within an integrated context should be able to evaluate their agility, complexity, effectiveness, and worth based on such KPIs. Even though the study's output is As a percentage of overall services, new created services and utilized e proportion and percent of finished tasks (services) performed in one sprint are determined to use these two indicators. 2 Team velocity e length of time it takes to build a service and the average length of time it takes to develop a service Such three factors track the team's efforts for a service that should be delivered within a sprint in regard to persprint and duration. ese metrics could be combined to determine SOA and SCRUM integration by developing a team velocity metric. 3 Customer satisfaction Confirmation of quality of service When adopting the SCRUM developmental methodological framework, certain metrics can be employed to assess the efficiency of service. Both measures have quality as a common attribute, and they can be utilized to provide the metric for evaluating SOA and SCRUM integration. 4 Team enthusiasm Violation of architecture policies e team members will interact in a friendly, collaborative fashion when they are happy, content, and working in a pleasant environment. ey will devote their whole attention and concentration to product development, ensuring that product quality remains standard. ey will also obediently observe the predetermined architectural policies and rules. We can also produce a huge number of high-quality services in a short length of time if the SCRUM team is happy and in a relaxing environment. As a result, we can say that the SCRUM metrics "team excitement & communication", "violations of architecture policies", and "median period to service creation" is dependent and also can affect the project when they were not targeted. Within the development platform, such metrics are employed to assess how employees adhere to rules and processes.

5
Team communication Average time to service development 6 Advancement of the process in retrospect Availability and usefulness of the service A single SCRUM and SOA metric can be created by combining the two metrics. Because all SCRUM procedures conclude with a retrospective meeting, it is the last opportunity to revive the overall activities. Whenever these services get completed in a sprint, an evaluation meeting will be conducted to evaluate the produced service's performance and usefulness, such as how to access the service & how it operates.
7 Control of technological debt Project and maintenance costs are reduced e major goal of these two measures is to lower product development costs by making the maximum use of resources and team members' abilities. ese two measures can be combined into a single metric to allow SCRUM and SOA techniques to be used together.
accurate, the researcher highlights several constraints which must be carefully evaluated before implementing the conclusions to a SCRUM and SOA integrated project in the enterprise [58, 59].

Future Work
is research work has been done according to the study scope and domain but some work is remaining in a domain that could be future research directions. For better understanding, SCRUM can be used as a process model in a distributed environment. In addition, to determine what effect SCRUM and SOA combination will have on project performance when it is employed in a distributed development environment, a system for evaluating and identifying metrics and KPIs should be established in all integrated SCRUM and SOA projects, whether distributed or not.

Data Availability
ere is no data available.

Conflicts of Interest
e authors claim that this paper does not include any conflicts of interest.