Fig 1 - uploaded by Esra Alzaghoul
Content may be subject to copyright.
Technical Debt positions on service-level in CB-SOA.

Technical Debt positions on service-level in CB-SOA.

Source publication
Conference Paper
Full-text available
A Cloud-based Service-Oriented Architecture (CBSOA) is typically composed of web services, which are offered off the cloud marketplace. CB-SOA can improve its utility and add value to its composition by switching among its constituent services. We look at the option to defer the decision of substitution under uncertainty. We exploit Binomial Option...

Contexts in source publication

Context 1
... manage the technical debt on the service level by switching from one web service to another and we consider cost and value along the option lifetime. Figure 1 illustrates three different possible situations of Technical Debt on the ServiceLevel. It describes patterns, which are related to some selection challenges described above. ...
Context 2
... describes patterns, which are related to some selection challenges described above. For example, the unintentional technical debt may occur due to unsuitable web service selection and may accumulate on the current web service before switching (T D W Scurr ), illustrated in Figure 1-part(A). The second type of technical debt, which is the intentional one, may for instance occur on the rework cost (T D RW ) due to switching as we decide to take on the technical debt in order to gain future value-added, illustrated in Figure 1part(B). ...
Context 3
... example, the unintentional technical debt may occur due to unsuitable web service selection and may accumulate on the current web service before switching (T D W Scurr ), illustrated in Figure 1-part(A). The second type of technical debt, which is the intentional one, may for instance occur on the rework cost (T D RW ) due to switching as we decide to take on the technical debt in order to gain future value-added, illustrated in Figure 1part(B). Furthermore, Figure 1-part(C) illustrates our third case scenario when we decide to minimize the unintentional technical debt by exercising an option, which can carry its own debt (intentional T D W Snew ). ...
Context 4
... second type of technical debt, which is the intentional one, may for instance occur on the rework cost (T D RW ) due to switching as we decide to take on the technical debt in order to gain future value-added, illustrated in Figure 1part(B). Furthermore, Figure 1-part(C) illustrates our third case scenario when we decide to minimize the unintentional technical debt by exercising an option, which can carry its own debt (intentional T D W Snew ). Though the option is deemed to be a debt, it is likely to unlock future value-added (V t W Snew ) on the structure and clear the debt. ...
Context 5
... 9 shows the derivation of the propagation cost metric for MySocialBook Architecture based on the approach described above. Then, according to [4], we compute the final density matrix by converting all non-zero cells in V matrix to ones (Figure 10). Accordingly, the propagation cost is computed as follows: 13 25 = 52%. ...
Context 6
... debt will increase with the introduced complexity as a result of substitution. Finally, we compute the "Complexity Density Matrix" by reflecting the dependency complexity levels (Figure 11). Despite the fact that two services may be dependent, the complexity of the dependency may vary. ...
Context 7
... manage the technical debt on the service level by switching from one web service to another and we consider cost and value along the option lifetime. Figure 1 illustrates three different possible situations of Technical Debt on the ServiceLevel. It describes patterns, which are related to some selection challenges described above. ...
Context 8
... describes patterns, which are related to some selection challenges described above. For example, the unintentional technical debt may occur due to unsuitable web service selection and may accumulate on the current web service before switching (T D W Scurr ), illustrated in Figure 1-part(A). The second type of technical debt, which is the intentional one, may for instance occur on the rework cost (T D RW ) due to switching as we decide to take on the technical debt in order to gain future value-added, illustrated in Figure 1part(B). ...
Context 9
... example, the unintentional technical debt may occur due to unsuitable web service selection and may accumulate on the current web service before switching (T D W Scurr ), illustrated in Figure 1-part(A). The second type of technical debt, which is the intentional one, may for instance occur on the rework cost (T D RW ) due to switching as we decide to take on the technical debt in order to gain future value-added, illustrated in Figure 1part(B). Furthermore, Figure 1-part(C) illustrates our third case scenario when we decide to minimize the unintentional technical debt by exercising an option, which can carry its own debt (intentional T D W Snew ). ...
Context 10
... second type of technical debt, which is the intentional one, may for instance occur on the rework cost (T D RW ) due to switching as we decide to take on the technical debt in order to gain future value-added, illustrated in Figure 1part(B). Furthermore, Figure 1-part(C) illustrates our third case scenario when we decide to minimize the unintentional technical debt by exercising an option, which can carry its own debt (intentional T D W Snew ). Though the option is deemed to be a debt, it is likely to unlock future value-added (V t W Snew ) on the structure and clear the debt. ...
Context 11
... 9 shows the derivation of the propagation cost metric for MySocialBook Architecture based on the approach described above. Then, according to [4], we compute the final density matrix by converting all non-zero cells in V matrix to ones (Figure 10). Accordingly, the propagation cost is computed as follows: 13 25 = 52%. ...
Context 12
... debt will increase with the introduced complexity as a result of substitution. Finally, we compute the "Complexity Density Matrix" by reflecting the dependency complexity levels (Figure 11). Despite the fact that two services may be dependent, the complexity of the dependency may vary. ...

Similar publications

Conference Paper
Full-text available
Cloud-based Service-Oriented Architectures are composed of web services, offered via the cloud. The substitution decision may introduce technical debt, which needs to be managed, cleared and transformed to value-added. We define the concept of technical debt for Cloud-based SOA. We formulate the problem of web service substitution and its technical...

Citations

... Regarding the TD management of microservicebased application, we can find a variety of studies that are focused on defining what can be considered as technical debt in SOA and how it can be quantified. For the quantification of TD in service-based systems all related studies focus outside the code of each service and explore the composition of the services [19]. For instance, de Toledo et al. [8] organized an industrial case study to identify (among others) what is TD in SOA. ...
Conference Paper
Service-Oriented Architectures (SOA) have become a standard for developing software applications, including but not limited to cloud-based ones and enterprise systems. When using SOA, the software engineers organize the desired functionality into self-contained and independent services, that are invoked through end-points (API calls). At the maintenance phase, the tickets (bugs, functional updates, new features, etc.) usually correspond to specific services. Therefore, for maintenance-related estimates it makes sense to use as unit of analysis the service-per se, rather than the complete project (too coarse-grained analysis) or a specific class (too fine-grained analysis). Currently, some of the most emergent maintenance estimates are related to Technical Debt (TD), i.e., the additional maintenance cost incurred due to code or design inefficiencies. In the literature, there is no established way on how to quantify TD at the service level. To this end, in this paper, we present a novel methodology to measure the TD of each service considering the underlying code that supports the corresponding endpoint. The proposed methodology relies on the method call graph, initiated by the service end-point, and traverses all methods that provide the service functionality. To evaluate the usefulness of this approach, we have conducted an industrial study, validating the methodology (and the accompanying tool) with respect to usefulness, obtained benefits, and usability.
... In addition, K-means clustering was used in many other fields, such as system management [29], energy consumption [21], service selection [30,31], and technical debt management [32]. For instance, Brentan et al. [29] presented a hybrid approach to improve planning, operation, and management in water distribution systems based on K-means clustering. ...
Article
Full-text available
Geospatial data analysis can be improved by using data-driven algorithms and techniques from the machine learning field. The aim of our research is to discover interrelationships among topographical data to support the decision-making process. In this paper, we extracted topographical geospatial data from digital elevation model (DEM) raster images, and we discovered hidden patterns among this data based on the K-means clustering algorithm, to uncover relationships and find clusters of elevation values for the area of Jordan. We introduce a method for querying and clustering geospatial data and we built an interactive map accordingly. The method discovers hidden patterns and uncovers relationships in given large datasets. We demonstrate the applicability of the method using the Jordan map and we report on geospatial data analysis and retrieval improvements. The results show that the optimal decision is in favor of four clusters (classes). The first class includes the high elevation values, the second class includes the very low elevation values, the third class includes the medium-high elevation values, and the fourth class includes the very high elevation values.
... With relevance to this thesis and with respect to uncertainty in electricity prices, ROA has been used for assessing investments in electricity generation capacities (Deng and Oren 2003;Martinez-Cesena et al. 2013;Ronn 2003) and flexible electricity consumption (Fridgen et al. 2015b;Oren 2001;Sezgen et al. 2007). Cloud computing research as well has applied ROA to support timing, staging, and termination decisions (Alzaghoul and Bahsoon 2014;Jede and Teuteberg 2016;Naldi and Mastroeni 2016;Yam et al. 2011). Paper 4 (p. ...
Thesis
The insight that demand flexibility bears value under uncertain price development is fundamental to this thesis, which studies such flexibility in timing the procurement of exchange-traded goods. When market prices vary, it can be possible to fulfill time-independent requests for a given product or service at lower prices. In that sense, the thesis addresses electricity and cloud computing, which both can be considered nonstorable goods that require immediate consumption. Therefore, both the established, liberalized electricity market and the rapidly growing cloud computing market could make beneficial use of short-term demand flexibility. The involvement of information systems and technology facilitates that use and makes it likely for these two markets to be more closely interrelated in the future. Consequently, this thesis provides an outlook on market structures that may become more relevant in the future. It unites four research papers and contextualizes their contribution. Two research papers advise on scheduling flexible demand in electricity markets (Paper 1 — Providing Utility to Utilities: The Value of Information Systems Enabled Flexibility in Electricity Consumption) and a cloud computing market (Paper 4 — Scheduling Flexible Demand in Cloud Computing Spot Markets: A Real Options Approach). Both papers introduce real option models and analytical algorithms for evaluating temporal demand flexibility in the respective markets. Options to reduce electricity costs or to join microgrids as decentralized consumption structures can shape demand flexibility. In a mixed methods research approach, Paper 2 — Electronic Markets for Electricity Procurement by SMEs: Determining Price-Impacting Factors and their Influence on the Outcome of Electronic Reverse Auctions — investigates price-impacting factors when companies auction their electricity supply in an innovative form of electricity procurement. Paper 3 — Framing Microgrid Design from a Business and Information Systems Engineering Perspective: A Framework and Agenda for Research — systematizes the microgrid construct. This thesis thus contributes to understanding and embracing new possibilities opened up by information systems, such as electronic spot markets and exchange trade, electronic reverse auctions, automated load shifting decisions, and microgrids.
... By contrast, the cloud computing paradigm solves much of this limitation, thereby allowing auto-configuration, providing reliable access, and overcoming heterogeneity. However, the cloud also comes with disadvantages, such as delay, scale, real-time processing, and cost [25]. ...
Article
Full-text available
Fog-computing is a new network architecture and computing paradigm that uses user or near-users devices (network edge) to carry out some processing tasks. Accordingly, it extends the cloud computing with more flexibility the one found in the ubiquitous networks. A smart city based on the concept of fog-computing with flexible hierarchy is proposed in this paper. The aim of the proposed design is to overcome the limitations of the previous approaches, which depends on using various network architectures, such as cloud-computing, autonomic network architecture and ubiquitous network architecture. Accordingly, the proposed approach achieves a reduction of the latency of data processing and transmission with enabled real-time applications, distribute the processing tasks over edge devices in order to reduce the cost of data processing and allow collaborative data exchange among the applications of the smart city. The design is made up of five major layers, which can be increased or merged according to the amount of data processing and transmission in each application. The involved layers are connection layer, real-time processing layer, neighborhood linking layer, main-processing layer, data server layer. A case study of a novel smart public car parking, traveling and direction advisor is implemented using IFogSim and the results showed that reduce the delay of real-time application significantly, reduce the cost and network usage compared to the cloud-computing paradigm. Moreover, the proposed approach, although, it increases the scalability and reliability of the users’ access, it does not sacrifice much time, nor cost and network usage compared to fixed fog-computing design.
... Ostatní publikovali jen jeden dokument a tato skutečnost se opět zdá být potvrzením, že propojení metod není lehce uchopitelné nebo v podobě, popsané autory není z hlediska dalšího zkoumání "zajímavé". jsou otázky přechodu z jedné služby na jinou [98], zvažováním dvou různých růstových opcí [99] a hodnocením časové flexibility prostřednictvím vyčkávací opce [100]. ...
... However, TD can be related to other activities as well, including design, documentation, and testing [12]. For example, in a recent study, Alzaghoul and Bahsoon (2013) [13] introduce a new perspective of TD in cloud computing services related to the selection, composition, and operation of services. Non-compliance in service level agreements (SLA), quick selection decisions with a lack of consideration for risk reduction and probable future changes, and under-utilization of web service capacity were identified as TD dimensions in the context of cloud services [13]. ...
... For example, in a recent study, Alzaghoul and Bahsoon (2013) [13] introduce a new perspective of TD in cloud computing services related to the selection, composition, and operation of services. Non-compliance in service level agreements (SLA), quick selection decisions with a lack of consideration for risk reduction and probable future changes, and under-utilization of web service capacity were identified as TD dimensions in the context of cloud services [13]. ...
Article
Context: Technical debt (TD) is a metaphor that is used to communicate the consequences of poor software development practices to non-technical stakeholders. In recent years, it has gained significant attention in agile software development (ASD). Objective: The purpose of this study is to analyze and synthesize the state of the art of TD, and its causes, consequences, and management strategies in the context of ASD. Research Method: Using a systematic literature review (SLR), 38 primary studies, out of 346 studies, were identified and analyzed. Results: We found five research areas of interest related to the literature of TD in ASD. Among those areas, “managing TD in ASD” received the highest attention, followed by “architecture in ASD and its relationship with TD”. In addition, eight categories regarding the causes and five categories regarding the consequences of incurring TD in ASD were identified. “Focus on quick delivery” and “architectural and design issues” were the most popular causes of incurring TD in ASD. “Reduced productivity”, “system degradation” and “increased maintenance cost” were identified as significant consequences of incurring TD in ASD. Additionally, we found 12 strategies for managing TD in the context of ASD, out of which “refactoring” and “enhancing the visibility of TD” were the most significant. Conclusion: The results of this study provide a structured synthesis of TD and its management in the context of ASD as well as potential research areas for further investigation.
... The need for establishing a metric to manage effectively the technical debt, when delivering a product, is also emphasized in [21], pointing out that the value of the delivered features and the impact of the cost should be considered in the decision-making process. On the other hand, an economics-driven approach in cloud-based architectures is discussed in [22], where the problem of the web service substitution and its technical debt valuation is described as an option problem, while a critical evaluation of the technical debt in cloud-based architectures using real options is performed in [23]. ...
Conference Paper
As network bandwidth and coverage continue to increase, the adoption rates of mobile devices are growing over time and the mobile technology is becoming increasingly industrialized. In mobile cloud marketplaces, the cloud-supported mobile services can be leased off. However, the mobile service selection may introduce technical debt (TD), which is essential to be predicted and quantified. In this context, this paper examines the incurrence of technical debt in the future when leasing cloud-based mobile services by proposing a novel quantitative model, which adopts a linear and symmetric approach as a linear growth in the number of users is predicted. The formulation of the problem is based on a cost-benefit analysis, elaborating on the potential profit that could be obtained if the number of users would be equal to the maximum value. The probability of overutilization of the selected service in the long run is also researched. Finally, a quantification tool has been developed as a proof of concept (PoC), which initiates the technical debt analysis and optimization on mobile cloud-based service level and aims to provide insights into the overutilization or underutilization of a web service when a linear increase in the number of users occurs.
... An architecture and measurement-based perspective is researched in [20], as the need for establishing a metric to manage effectively the technical debt when delivering a product, is motivated. Additionally, an economics-driven approach in cloud-based architectures is discussed in [21], while a critical evaluation using real options is performed in [22]. ...
Conference Paper
Full-text available
Enterprise mobility has become a top technology priority for companies over recent years and many organizations are accelerating the adoption of mobile cloud application models. The mobile cloud can be considered as a marketplace, where the mobile services of the mobile cloud-based system architectures can be leased off via the cloud. In this context, this paper elaborates on a novel fluctuation-based quantification model, which is based on a cost-benefit appraisal, adopting a non-linear and asymmetric approach. The proposed model aims to predict the incurrence and the risk of entering into a new technical debt (TD) in the future and provide insights to inform effective investment decision making. The lease of a cloud-based mobile service was considered, when developing the formula, and the research approach is investigated with respect to the cost that derives from the unused capacity. The probability of overutilization or underutilization of the selected service is examined, as fluctuations in the number of users are forecasted. A quantification tool has been also developed as a proof of concept, implementing the proposed model and intending to quantify and evaluate the technical debt on mobile cloud-based service level, when fluctuations in the demand occur.
... Cost-benefit analysis 11 [Stochel, 2012] [Holvitie and Ville, 2013] [Monteith and McGregor, 2013] [ Alzaghoul and Bahsoon, 2014] [ Ojameruaye and Bahsoon, 2014] [ Ramasubbu and Kemerer, 2014] [9] [Holvitie, 2014] Portfolio Approach 10 [Stochel, 2012] [Snipes et al., 2012] [Power, 2013] [ [Ken, 2013] [ Alzaghoul and Bahsoon, 2014] [ Ojameruaye and Bahsoon, 2014] Options 6 [ Alzaghoul and Bahsoon, 2014] [ Ojameruaye and Bahsoon, 2014] Analytic hierarchy process 3 [Alzaghoul and Bahsoon, 2014] [ Ojameruaye and Bahsoon, 2014] Calculation of TD-principal 2 [Curtis et al., 2012b] Marking of dependencies and code issues [Morgenthaler et al., 2012] 2 [Tom et al., 2013] Debt symptoms index [Marinescu, 2012] 1 Empirical model of technical debt and interest [Nugroho et al., 2011] 1 Formal approach to technical debt decision making 1 Game theoretic competitive source control approach [Morrison-Smith et al., 2012] 1 Measuring symptom severity on a smell thermometer [Ligu et al., 2013] 1 Metric for managing architectural technical debt 1 RE-KOMBINE model [Ernst, 2012] 1 SQALE method [Letouzey and Ilkiewicz, 2012] 1 Supply chain management 1 Framework for estimating interest [Singh et al., 2014] 1 Managing TD in database schemas [Weber et al., 2014] 1 Benchmarking-based model [Mayr et al., 2014] 1 Model for optimizing technical debt [Ramasubbu and Kemerer, 2013] 1 Finance and accounting practices [Conroy, 2012] 1 Finally, the mapping study presented in this work considers papers published up to 2014. Specifically, this means 27 additional papers published in the last year selected for analysis. ...
... Cost-benefit analysis 11 [Stochel, 2012] [Holvitie and Ville, 2013] [Monteith and McGregor, 2013] [ Alzaghoul and Bahsoon, 2014] [ Ojameruaye and Bahsoon, 2014] [ Ramasubbu and Kemerer, 2014] [9] [Holvitie, 2014] Portfolio Approach 10 [Stochel, 2012] [Snipes et al., 2012] [Power, 2013] [ [Ken, 2013] [ Alzaghoul and Bahsoon, 2014] [ Ojameruaye and Bahsoon, 2014] Options 6 [ Alzaghoul and Bahsoon, 2014] [ Ojameruaye and Bahsoon, 2014] Analytic hierarchy process 3 [Alzaghoul and Bahsoon, 2014] [ Ojameruaye and Bahsoon, 2014] Calculation of TD-principal 2 [Curtis et al., 2012b] Marking of dependencies and code issues [Morgenthaler et al., 2012] 2 [Tom et al., 2013] Debt symptoms index [Marinescu, 2012] 1 Empirical model of technical debt and interest [Nugroho et al., 2011] 1 Formal approach to technical debt decision making 1 Game theoretic competitive source control approach [Morrison-Smith et al., 2012] 1 Measuring symptom severity on a smell thermometer [Ligu et al., 2013] 1 Metric for managing architectural technical debt 1 RE-KOMBINE model [Ernst, 2012] 1 SQALE method [Letouzey and Ilkiewicz, 2012] 1 Supply chain management 1 Framework for estimating interest [Singh et al., 2014] 1 Managing TD in database schemas [Weber et al., 2014] 1 Benchmarking-based model [Mayr et al., 2014] 1 Model for optimizing technical debt [Ramasubbu and Kemerer, 2013] 1 Finance and accounting practices [Conroy, 2012] 1 Finally, the mapping study presented in this work considers papers published up to 2014. Specifically, this means 27 additional papers published in the last year selected for analysis. ...
... Cost-benefit analysis 11 [Stochel, 2012] [Holvitie and Ville, 2013] [Monteith and McGregor, 2013] [ Alzaghoul and Bahsoon, 2014] [ Ojameruaye and Bahsoon, 2014] [ Ramasubbu and Kemerer, 2014] [9] [Holvitie, 2014] Portfolio Approach 10 [Stochel, 2012] [Snipes et al., 2012] [Power, 2013] [ [Ken, 2013] [ Alzaghoul and Bahsoon, 2014] [ Ojameruaye and Bahsoon, 2014] Options 6 [ Alzaghoul and Bahsoon, 2014] [ Ojameruaye and Bahsoon, 2014] Analytic hierarchy process 3 [Alzaghoul and Bahsoon, 2014] [ Ojameruaye and Bahsoon, 2014] Calculation of TD-principal 2 [Curtis et al., 2012b] Marking of dependencies and code issues [Morgenthaler et al., 2012] 2 [Tom et al., 2013] Debt symptoms index [Marinescu, 2012] 1 Empirical model of technical debt and interest [Nugroho et al., 2011] 1 Formal approach to technical debt decision making 1 Game theoretic competitive source control approach [Morrison-Smith et al., 2012] 1 Measuring symptom severity on a smell thermometer [Ligu et al., 2013] 1 Metric for managing architectural technical debt 1 RE-KOMBINE model [Ernst, 2012] 1 SQALE method [Letouzey and Ilkiewicz, 2012] 1 Supply chain management 1 Framework for estimating interest [Singh et al., 2014] 1 Managing TD in database schemas [Weber et al., 2014] 1 Benchmarking-based model [Mayr et al., 2014] 1 Model for optimizing technical debt [Ramasubbu and Kemerer, 2013] 1 Finance and accounting practices [Conroy, 2012] 1 Finally, the mapping study presented in this work considers papers published up to 2014. Specifically, this means 27 additional papers published in the last year selected for analysis. ...
Article
Context The technical debt metaphor describes the effect of immature artifacts on software maintenance that bring a short-term benefit to the project in terms of increased productivity and lower cost, but that may have to be paid off with interest later. Much research has been performed to propose mechanisms to identify debt and decide the most appropriate moment to pay it off. It is important to investigate the current state of the art in order to provide both researchers and practitioners with information that enables further research activities as well as technical debt management in practice. Objective This paper has the following goals: to characterize the types of technical debt, identify indicators that can be used to find technical debt, identify management strategies, understand the maturity level of each proposal, and identify what visualization techniques have been proposed to support technical debt identification and management activities. Method A systematic mapping study was performed based on a set of three research questions. In total, 100 studies, dated from 2010 to 2014, were evaluated. Results We proposed an initial taxonomy of technical debt types, created a list of indicators that have been proposed to identify technical debt, identified the existing management strategies, and analyzed the current state of art on technical debt, identifying topics where new research efforts can be invested. Conclusion The results of this mapping study can help to identify points that still require further investigation in technical debt research.
... [5], [6], [10], [15], [16], [17], [19], [20], [22], [23], [24], [25], [28], [29], [30], [31], [33], [41], [42], [45], [46], [47], [48], [49], [50], [51] E3 Interest estimation ...
... [5], [6], [10], [15], [16], [17], [19], [20], [22], [23], [24], [25], [28], [29], [30], [31], [33], [41], [42], [45], [46], [47], [48], [49], [50] E4 Interest probability estimation ...
... [5], [6], [7], [8], [10], [12], [13], [15], [16], [17], [19], [20], [21], [22], [23], [24], [25], [26], [27], [29], [31], [33], [35], [36], [38], [39], [41], [42], [45], [46], [47], [48], [50], [52], [53], [54], [55] T2 Cost estimation techniques E6 Automated estimates ...
Conference Paper
Full-text available
Current technical debt management approaches mainly address specific types of technical debt. This paper introduces a framework to aid in decision making for technical debt management, and it includes those elements considered in technical debt management in the available literature, which are classified in three groups and mapped into three stakeholders' points of view. The research method was systematic mapping. In contrast to current approaches, the framework is not constrained by a concrete type of technical debt. Using this framework it will be possible to build specific models to assist in decision making for technical debt management.