Extending software architecture views with an energy consumption perspective

Until recently the focus has mostly been on hardware related aspects as improvements on hardware level are relatively tangible and easy to apply, e.g. renewal of hardware. However, in [20] the role of software is also stressed in finding sustainable (ICT) solutions. While energy is directly consumed by hardware, the operations are directed by software and can eliminate any sustainable features built into the hardware [33]. Thus software is argued to be the true consumer of power [34].

In [12] a decrease in EC of 0.25 W with four million installations is presented to save the EC equivalent to that of an American household per month, showing that even the smallest change could have a major impact.

One of the main issues with respect to green software is to perform detailed EC measurements. Specialized environments, e.g. [10], enable measurements on each individual hardware component and provide detailed insight into how software affects these components. In these setups, the EC of software is measured by relating the EC of hardware to computational resource usage on behalf of the software and, consequently, energy efficiency refers to the efficient use of computational resources [11]. However, these environments are rare, difficult to expand to more complex environments (e.g. data canter) and only few are able (and willing) to invest in the equipment required for such a solution. At the cost of details, external power measurement equipment can also be used.

EC measurements become even more complex when the entire computing stack is in play, as each layer between software and hardware level (e.g. operating system, virtual machine) is said to amplify the EC induced by the software [6].

In [9] ’Green Performance Indicators’ (GPIs) are proposed for these environments that, apart from EC measurements, require detailed performance monitoring to assign (portions of) the EC to specific software elements.

An advantage of using the SA is to address concerns related to EC in an early stage of the software life cycle, namely during its design. Through the architecture, a product manager, that determines the strategic direction (including green goals) for a product [8], has a means to address his concerns in the product design [31] and determine whether the desired quality of service is achieved [19]. From an organizational perspective such an approach emphasizes the role that green software can play in reaching sustainability goals. On this level, green software has the potential to reduce the operational costs related to a software product, enabling sustainability on the economical dimension [7].

From literature study [4,11,16–18], software utilization, energy usage and workload energy were distilled as potential quality properties: – Software utilization is the degree to which resources specifically utilized on the account of a software product meet requirements. – Energy usage is the degree to which the amount of energy used by a software product meets requirements. – Workload energy is the degree to which the EC related to performing a specific task using a software product meets requirements. The first two properties represent the low-level measurements, whereas the latter is used to characterize a software product in such a way that it facilitates discussion between stakeholders [11].

In Table 1 a list is proposed of the quality properties, measures and measure elements identified for the ‘resource consumption’ subcharacteristic, including a definition of the quality measure and a measurement function containing quality measure elements. For example, the task energy consumption quality measure (measure for the energy consumed while performing a task) is calculated by subtracting the idle EC from the EC while operating and divide by the number of tasks performed.Asthelistisa starting point and by no means definitive, it could be changed or extended based on new insights.

To increase the applicability of the measures, we decided to provide quality measure elements that can be either directly measured or derived from the total EC. For the measurement method this implies that performance monitoring tooling is required, ideally on the level of individual hardware components and processes, as well as tooling to perform EC measurements. For the latter both software and hardware solutions exist, capable of measuring at least the total power or EC for a system. Combining measurements from these sources in the measurement functions, provides the required information to quantify the subcharacteristics. Applying the measurement method might require more effort as environments become more complex. Shared resources, for example, require detailed performance measurements to allocate EC to specific instances of software.

A concrete trade-off related to EC is on the balance between demand and supply in resource allocation [39]. If more computational resources are available than required for a task, this should not automatically mean that extra resource should be assigned to this task (i.e. sustainability versus performance).

To address concerns for a software product on the level of the SA, tactics are applied. A tactic is a decision that influences the control of a QA [2] and is a design option that helps the architect in realizing a desired property for a system.

In [29] a catalog is presented consisting of the energy monitoring, self-adaptation and cloud federation categories. The categories are aimed at respectively collecting power consumption information on infrastructure and software component level, optimizing during run-time and finding the most energy efficient services to perform a task, and include several tactics that address energy efficiency in the cloud.

In terms of database calls, software consisting of fewer modules could require less calls while significantly more data is transferred per call. When software consists of more modules, an increase in database calls could be observed with the potential that less data is transferred per call, i.e. the calls are more fitted to the process at hand. In this case less CPU capacity is required for processing the call, lowering the EC per call.

Although modularity can positively affect the EC of software [35], more modules also implies a higher communication load. When the number of modules increases, depending on the deployment, the communication load that is induced on the infrastructure also increases.

Ineffective use of hardware is a common source for energy inefficiency and is one of the triggers to consolidate the number of active servers within a data center. From an EC point of view there is less hardware in absolute terms reducing the idle energy consumption and the available hardware is used more effectively.

Concurrency architecture variation [38]
In this specific case the Half Synchronous/Half Asynchronous and the Leader/Followers concurrency architectures are compared and a significant difference was found in the advantage of the first.

As an initial validation of the perspective, a case study was performed in which the perspective was applied to a commercial software product. The energy profile that was created directed us to the architectural element that was the main driver behind the EC and through an architectural change we managed to reduce the energy consumption of DG with 67.1 % per generated document. Considering the frequency at which this task is performed and the number of DG deployments, the savings could add up significantly from an organizational dimension.

Green architectural tactics:

• Increase modularity
• Network load optimization
• Increase hardware utilization
• Concurrency architecture variation