Software sustainability: Research and practice from a software architecture viewpoint

Modern society's reliance on 'dangerously fragile' software [Booch, 2015] has resulted in the emergence of software sustainability as a growing area of interest in the field of software engineering [Venters et al., 2014a]. The Karlskrona Manifesto [Becker et al., 2014] reflects this new trend by providing a focal point for establishing a common ground for the software engineering community to engage. It argues that designers of software technology are responsible for the long-term consequences of their designs - a position also supported by Cerf [2017] - and proposes a set of key principles and commitments that underpin sustainability design.

In relation to software, there exist at least two distinct viewpoints for the topic area of software and sustainability: sustainable software and software engineering for sustainability (SE4S). The former is concerned with the principles, practices, and processes that contribute to software endurance, i.e. technical sustainability, and the latter focuses on software systems to support one or more dimensions of sustainability, concerning issues outside the software systems itself [Penzenstadler, 2013].

The Karlskrona Manifesto [Becker et al., 2014] recognises both viewpoints of software sustainability as an emerging concern of central relevance and advocates that sustainability must be viewed as a construct across five dimensions: environmental, economic, individual, social and technical [Becker et al., 2015].

IT systems as well as cars require energy and therefore have an impact on the environment, e.g. through emissions. Furthermore, there is a lifecycle for the respective hardware parts that have to be resourced from somewhere, manufactured, maintained, and eventually disposed of or recycled. In a sharing system, the bottom line usage of resources often decreases, which reduces its environmental impact [Wadud et al., 2016].

In addition, several of the quality attributes specify the effort required to achieve a particular outcome. This suggests that the concept of sustainability is strongly coupled to other quality attributes such as energy and cost efficiency, and resource utilisation over the software's entire lifetime and aligns with the dimensions of environmental and economic sustainability.

In the area of software engineering and sustainability, a number of reference models to develop sustainable software (i.e. a system that requires less maintenance effort to be changed or reduces its energy consumption during execution saving the resources as well) have been proposed. For example, Naumann et al., [2011] proposed the GREENSOFT model for the development of sustainable software; a conceptual reference model, which includes a cradle-to-grave product life cycle model for software products, sustainability metrics and criteria for software, and extensions for software engineering. The model covers development, distribution, usage, deactivation and disposal of software systems, and offers two categories of sustainability criteria and metrics for software products covering direct and long-term impact. Similarly, Mahmoud and Ahmad [2013] propose a development model aimed at supporting (environmentally) sustainable software engineering that includes a list of metrics to measure the environmental sustainability of each software engineering phase.

In this article, we distinguish the five dimensions that articulate concerns of relevance and provide a scope for the indicators and concepts required to understand the capacity of realworld cyber-physical and socio-technical systems to endure.

Software sustainability. The capacity of the software-intensive system itself to endure will be a concern for the operating organisation and the community [Becker et al., 2015].

Software architecture sustainability. The capacity of that software system to endure in turn is contingent upon its structures and their ability to evolve. This is often referred to as architecture sustainability (i.e. the degree to which the architecture of the software system supports its continued maintenance and evolution over time without requiring substantial and expensive restructuring) [Koziolek, 2011].

Sustainable software architecture design decisions. This architecture, in turn, reflects the foundational design decisions that structure the system and its elements, so decision making is increasingly a focus of attention (van Vliet & Tang, 2016). Because architectural decisions have long-lasting effects and are expensive to revise, the capacity of each decision to remain valid is a primary concern to the architects. This notion has been described as the sustainability of software architecture design decisions (Zdun et al., 2013).

Software systems are directly dependent on their architectural design to ensure their longterm use, efficient maintenance, and appropriate evolution in a continually changing execution environment [Kruchten et al., 2016].

Many factors can lead to architecture erosion and drift, from the accumulation of wrong or sub-optimal design decisions to communication problems between design and development teams [Jaktman et al., 1999].

One approach to designing flexible, open software architectures that are sustainable is to pre-emptively design them to accommodate future changes to a greater extent without significant change to the basic structure of the system with minimal cost [Kim et al., 2014].

The emergence of software reference architectures, which embody the architectural knowledge of structures, elements and the relations of many successful architectural implementations, can provide templates for designing sustainable architectures albeit constrained to a particular domain or a family of software systems [Nakagawa, 2014].

Well-known reference architectures include: AUTOSAR2 for the automotive sector; Continua3 for health systems; OASIS Service-Oriented Foundation; IBM Service-Oriented Solution Stack (S3) for Service-Oriented Architectures (SOA); and the recent Industrial Internet Reference Architecture (IIRA).

The multi-faceted concept of "sustainability debt" (i.e. how technical debt can be used to identify and communicate about the effects of software design decisions on sustainability) discussed in Betz et al., [2015] reflects the hidden effect of past design decisions as a negative factor affecting the five sustainability dimensions including the economic issue of long-term costs.

However, the sustainability of designs rely not only on the quality of optimal design decisions but also on economic, individual, social, and technical factors required to capture those decisions including lack of motivation or incentive, lack of adequate tools, the effort in capturing architectural knowledge (AK), disrupting the design flow, lack of stakeholder understanding, and knowing what knowledge is relevant and valuable to capture which is especially challenging in Agile projects where documentation is reduced to a minimalistic set of data [Zimmermann, 2007].

The software architecture of a system is the product of a set of architectural design decisions. However, the knowledge of the architectural design decisions of a software-intensive system is easily lost, which leads to increased maintenance and evolution costs, and design erosion [Tofan, Galster and Avgeriou, 2011].

Critical to architectural sustainability is capturing decision viewpoints and their rationale as first-class elements of architectural descriptions. The ability to understand architectural design decision is crucial for the evolution of the system in measuring how sustainable the AK is during architectural changes and can provide an estimation of the maintenance and documentation effort needed when new requirements trigger new decisions.

The appearance of the different dimensions of technical debt [McConnell, 2007] [Fowler, 2009] as a quality indicator of suboptimal design decisions and coding practices, led software developers to keep this debt under control [Letouzey, 2012] to reduce the remediation cost of technical debt management. Therefore, we need to discover the root and sources of the debt [Kazman, 2015] and those "hot-spots" [Mo, 2015] in long-living systems to be able to measure software sustainability both in architecture and code [Le, 2016].

A number of approaches have investigated modularity metrics as an indicator of technical debt [Liang, 2014]

Koziolek et al. [2011] suggested a number of more than forty metrics that could be used to estimate software sustainability of software architecture including evolution concerns. Further work by Koziolek et al. [2013] limited the number of metrics to twelve. Garcia et al. [2009] introduced the concept of "architectural bad smell" (i.e., an anti-pattern or inadequate design practice that violates a well-established design principle) exemplified by anti-patterns, architectural mismatch, defects and code smells that impact on the quality of designs, detailing four of these architectural smells as a class of cumulative design problems that lead to architectural refactoring.

As a result of changing stakeholder requirements, software systems are the product of accidental complexity that presents significant challenges with regards to maintenance and evolution. While Brooks [1986] argues that complexity is an essential property of software it should not be accidental; this presents significant challenges and threats to ensure the dependability and longevity of software systems.

The concept of sustainability has emerged as a growing area of interest in the field of software engineering to address the challenges of designing software systems that can endure. This raises the question, what is the most efficient and effective method or approach for managing change and evolution regarding a software system?

Software architectures strongly influence sustainability, because they affect how developers can understand, analyse, extend, test and maintain a software system. As a result, software architectures the blueprint of how the software system will be built; they hold the key to postdeployment system understanding, maintenance, and evolution.

One approach to designing software architectures that are sustainable is adherence to established design principles enshrined in reference architectures, which embody the wisdom of reusable architectural knowledge of key design decisions and provide a common vocabulary and template solution for an architecture for specific domains or a family of software systems.