Sustainability Debt: A Metaphor to Support Sustainability Design Decisions

Sustainability, the capacity to endure, is fundamental for the societies on our planet. Despite its increasing recognition in software engineering, it remains difficult to assess the delayed systemic effects of decisions taken in requirements engineering and systems design. To support this difficult task, this paper introduces the concept of sustainability debt. The metaphor helps in the discovery, documentation, and communication of sustainability issues in requirements engineering. We build on the existing metaphor of technical debt and extend it to four other dimensions of sustainability to help think about sustainability-aware software systems engineering. We highlight the meaning of debt in each dimension and the relationships between those dimensions. Finally, we discuss the use of the metaphor and explore how it can help us to design sustainability-aware software intensive systems

Modernin Web-Sovelluksen Migraatio Pilviympäristöön

Web technologies have been evolving fast since the adaptation of the modern web, and new tools and frameworks keep on coming into existence. With rapidly evolving technologies, the risk of accumulating technical debt becomes more common and must be taken into account at various stages of a software project. At the same time, new ways of working are generalising throughout development teams to ensure the quality of these projects. The purpose of this thesis is to explore modern web technologies, methodologies, as well as different categories of technical debt that these might bring. It also takes a look into the public cloud and its most common cloud service providers and their services. Based on these, it proposes a strategy for bringing an existing web application onto a cloud environment. Based on the case study project and literature evaluation, it is concluded that any application undertaking any larger work would benefit from having its technical debt at a manageable level and codebase in a good shape. It is also seen that when dealing with modern technologies, said technical debt might accumulate more rapidly than with projects implemented with more established technologies. When it comes to hosting web applications on the cloud, it is concluded that while a platform migration might bring some benefits in itself, a larger restructuring and careful redesigning work might be called for in order to fully reap the benefits of the public cloud.Web-teknologiat ovat kehittyneet nopeasti modernin nettiympäristön myötä, ja uusia työkaluja sekä sovellusalustoja syntyy jatkuvasti. Nopeasti kehittyvien teknologioiden kanssa työskennellessä teknisen velan kerryttämisen riski yleistyy ja sitä pitää tarkkailla monessa eri sovelluksen elinkaaren osassa. Tämän työn tarkoituksena on tutkia moderneja web-teknologioita sekä metodologioita ja niiden mukana tulevan teknisen velan eri kategorioita. Työ tutkii myös julkipilveä alustana sekä tämän yleisimpiä palveluntarjoajia ja heidän tarjoamiaan palveluita. Näiden perustella ehdotetaan strategiaa, jolla modernin web-sovelluksen saa tuotua pilviympäristöön. Tapaustutkimuksen ja kirjallisuuskatsauksen perusteella todetaan, että mikä tahansa sovellus, jolla on edessä isompi työkokonaisuus, hyötyy siitä, että sen kerryttämä tekninen velka on hallittavalla tasolla sekä koodikanta hyvässä kunnossa. Nähdään myös, että työskennellessä modernien teknologioiden kanssa kyseinen tekninen velka saattaa syntyä nopeammin kuin projekteissa, joissa on käytetty pidempään olemassa olleita teknologioita. Web-sovellusten tarjoamisesta pilviympäristöissä voidaan todeta, että vaikka migratointityö voi tuoda itsessään joitain hyötyjä mukanaan, voi isompi uudelleenjärjestämis- ja suunnittelutyö olla paikallaan, jotta voidaan saada kaikki julkipilven hyödyt irti

Road to Microservices

This document intends to elucidate the complexity of microservices decomposition and this its inherent process of implementation. Developments in technology and design, achieving higher performance, reliability, or lowering costs are valid reasons to consider controlling the product’s quality by guaranteeing its conformance with established characteristics and standards. Control is made possible by adding quality control, inspection routines, and trend analysis to a manufacturing process. These techniques are established in the Quality field academically and business-wise. Repeat Part Management (RPM) is software that allows users to apply these techniques efficiently and has brought value to the company. However, RPM has been growing, and issues have emerged due to customer needs - accumulated technical debt. These ever-growing modifications are common through different business areas, and architectures’ research evolution has accompanied them. This demand for highly modifiable, rapid development, and independent systems has resulted in the adoption of microservices. There is a concern for existing systems for decomposition due to the characteristics of microservices, which encourages approach/technique research. This architecture promotes legacy system analysis to map current functionalities and dependencies between components. Furthermore, critical concepts in a microservices architecture are researched and implemented in a new system that encompasses Repeat Part Management’s functionalities. This thesis explores the microservices’ architecture evolution with an already defined mature domain in quality assessment.Este documento pretende especificar a complexidade do processo de decomposição em microsserviços e do seu processo de implementação. Avanços na tecnologia e design, alcançar melhor performance, ou a confiabilidade do produto, ou diminuir custos são justificações válidas para considerar controlar a qualidade do produto e, inerentemente, garantir a sua conformidade com as características previamente definidas e com padrões da indústria. É possível garantir controlo sob os produtos ao acrescentar, ao processo produtivo, métodos de controlo de qualidade, rotinas de inspeção e análise de tendências (de desvio). Estas técnicas estão bem estabelecidas academicamente e, de um ponto de vista do mercado, na área da Qualidade e garantia da qualidade. O Repeat Part Management (RPM) é um software que permite aos seus utilizadores a utilização eficiente destas técnicas de qualidade, o que resulta numa adição de valor para a empresa. Porém, devido às crescentes necessidades dos clientes, alguns problemas têm sido identificados - relacionados com o conceito de acumulação de technical debt. Esta crescente necessidade de alteração é comum em diversas áreas de negócio, e a investigação de soluções arquiteturais tem acompanhado esta pesquisa. Esta solução arquitetura pode ser caracterizada pela facilidade de sistemas facilmente modificáveis, pelo rápido desenvolvimento e implementação, e pela independência dos serviços decompostos. Aquando de uma migração para microsserviços num sistema maturo, existe uma maior preocupação na decomposição da aplicação e definição dos serviços dada a característica dos microsserviços, o que incentiva a uma pesquisa detalhada sobre as técnicas de decomposição. Pela mesma razão, esta arquitetura incentiva ao mapeamento e documentação das dependências entre serviços e componentes e o estudo da aplicação legacy. Para além disto, estes conceitos, e a sua implementação devem ser planeados, justificados e documentados, o que explica a complexidade do processo de migração e implementação, que deve ter em consideração as funcionalidades existentes no Repeat Part Management. Dessa forma, esta tese explora a implementação desta arquitetura numa aplicação matura na área de Garantia de Qualidade

Technical Debt Management: Definition of a Technical Debt Reduction Software Engineering Methodology for SMEs

In the past two decades, the metaphor of technical debt has gained significant importance in the field of software engineering. In general, the term is used to describe scenarios when instead of providing a proper solution for a given task, a sub-optimal implementation is used in order to gain short term benefits. Unfortunately, this kind of decisions can - and most of the time do - result in increased maintenance costs and poor evolvability in the long run. Over time, software practitioners further refined the initially source code-focused concept and started to apply the metaphor for a much wider range of software engineering inefficiencies, such as architectural defects, inappropriate documentation or low test coverage. Due to its similarity to financial debt, the analogy has also become a valuable communication tool in situations when there are less technical people involved in discussions. This master's thesis defines a technical debt reduction methodology, which can help SMEs to control the accumulation of technical debt. The proposed methodology can be thought of as a set of steps and good practices that facilitate the long-lasting productivity and profitability of SMEs. Since this field of research is relatively new, the need for publications addressing the topic is still rather high. Due to its numerous negative effects, it is crucial for companies to keep their debt levels as low as possible, which requires a systematic way of managing technical debt. Besides providing such a methodology, the document also intends to raise awareness about the nature and dangers of taking on unreasonable amounts of debt by examining the most important characteristics of the phenomenon. Finally, the thesis presents an industrial case study as well, which aims to showcase how some of the most necessary steps can be taken in practice

Business-Driven Technical Debt Prioritization

Technical debt happens when teams take shortcuts on software development to gain short-term benefits at the cost of making future changes more expensive. Previous results show that there is a misalignment between the prioritization done by technical professionals and the prioritization expected by business ones. This paper presents a business-driven approach to prioritize technical debt items. The research is organized into four phases: exploratory, to identify the research focus; concept verification, where the proposed approach was evaluated on a multi-case study; solution, where a design science research was conducted to develop Tracy, a framework for technical debt prioritization; and validation. Results so far show that the business-driven prioritization of technical debt items can improve the alignment and communication between the technical and business stakeholders.Comment: Preprint submitted to the 35th International Conference on Software Maintenance and Evolution (ICSME'19) (Doctoral Symposium). arXiv admin note: substantial text overlap with arXiv:1908.0015

Supporting Sustainability and Technical Debt-Driven Design Decisions in Software Architectures

Degraded software usually incurs higher energy consumption, therefore suboptimal decisions in software architectures may lead to higher technical debt and less sustainable software products. There are metrics and tools to calculate technical debt and energy consumption of software, but it is required to provide mechanisms to store their relationship and how they change depending on the design decisions. In addition, there are different models for calculating the same metric and different metrics to measure technical debt and power consumption, and software engineers require selecting the most suitable model and metric depending on the software product context. This work presents a metamodel called ARCMEL to provide the required base of knowledge for supporting green-aware design decisions and to flexibly configure and select metrics and their models. ARCMEL has been implemented as part of the ARCMEL SCAT tool. Its validation is also presented in terms of completeness and flexibility

Towards guidelines for building a business case and gathering evidence of software reference architectures in industry

Background: Software reference architectures are becoming widely adopted by organizations that need to support the design and maintenance of software applications of a shared domain. For organizations that plan to adopt this architecture-centric approach, it becomes fundamental to know the return on investment and to understand how software reference architectures are designed, maintained, and used. Unfortunately, there is little evidence-based support to help organizations with these challenges. Methods: We have conducted action research in an industry-academia collaboration between the GESSI research group and everis, a multinational IT consulting firm based in Spain. Results: The results from such collaboration are being packaged in order to create guidelines that could be used in similar contexts as the one of everis. The main result of this paper is the construction of empirically-grounded guidelines that support organizations to decide on the adoption of software reference architectures and to gather evidence to improve RA-related practices. Conclusions: The created guidelines could be used by other organizations outside of our industry-academia collaboration. With this goal in mind, we describe the guidelines in detail for their use.Peer ReviewedPostprint (published version