Extending software architecture views with an energy consumption perspective

Before continuing with the related work we introduce a case in the form of Document Generator (DG); a commercial software product used to generate over 30 million documents per year. DG is used by approximately 300 customers with 1000 end-users as a complementary product with other commercial software products.

The basic workflow for DG (right side of Fig. 1) is initiated by a trigger from an external application. After validation of the received input, DG collects the data and document definitions, managed in separate systems, and merges the data into a preview for approval. After approval, the actual generation is performed and the documents are archived (optionally in a DMS) and communicated to a required outlet.

Open image in new window

Figure 1 also includes a mapping of the workflow onto the functional architecture of DG. The ‘Connector’ element contains four sub-elements and is responsible for four of the six activities in the workflow, namely receiving input, collecting data, archiving and communicating. Together with the ‘Composer’ element, responsible for merging the document definitions with data, the ‘Connector’ element handles the required activities before and after document generation. ‘Utilities’ and ‘Interface’ respectively provide configuration options and an interface for DG and do not map onto an activity in the workflow. Finally the ‘Generator’ is responsible for the actual generation of the documents and corresponds to the generate activity.

For this research we focus on the application server including the connector.exe, config.exe, interface.exe and document.exe processes (i.e. concurrency units). Representative for an actual production installation, these processes run on a single server (i.e. deployment) which is labeled the ‘Application server’. The database server is considered out of scope for this research. In the remainder of this paper, the DG case is used to provide concrete examples for the perspective.

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.

Compared to hardware measurements, software approaches can specifically focus on the software under investigation and measure on more detailed levels. The ‘E-Surgeon’ solution [27] for example, enables its user to monitor the EC of software during runtime down to the classes and methods. Although promising results are obtained, applying the ‘E-Surgeon’ solution requires expert knowledge on the subject which potentially inhibits its adoption. The same holds for instrumenting the software [30]. A more simple software-only approach is to use energy profilers [26]; software tools including a power model with the ability to estimate the software EC on different levels of granularity. Unfortunately recent study has found energy profilers to not always provide the desired results [14].

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 the paradigm of ‘programmable web’ [5], end users can easily create applications tailored to their own needs. Without proper control of the layers at play, the explosion in number of applications could have disastrous effects on the EC of the underlying infrastructure. Since the impact of each layer is a research topic on its own, we consider this as future research and maintain focus on the software product and its architecture.

A final aspect with regard to EC measurements is the deployment of the software product. Nowadays, software is often distributed across multiple servers, or even across federated data centers, and resources are shared with other applications. 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. Obtaining the required data requires appropriate performance measurements and either a software or hardware approach for EC measurements, depending on the level of detail required.

While the hardware and software approaches for measuring have up- and down-sides to them, both serve the same purpose; identify ‘software energy hotspots’ [30] which are the measurable elements or properties that have a significant impact on the EC. The proposition of green software is to have software that requires the least amount of resources as possible while performing the required task(s).

From a software vendors’ perspective, investment in new hardware or optimizing the current hardware is considered less costly than having a slower development cycle. Currently, performance is optimized on hardware level and software engineers are instructed to write software at a high pace with the risk of delivering sub-optimal code and algorithms. It is the experience of the authors in industry that still too little is known with regard to the potential benefits of green software to create a valid business case. There is light on the horizon, however, with green software examples and guidelines becoming increasingly more available [3, 23, 25, 39] and concrete.¹ Even without changing the current practice of software engineers [25].

At its core the creation of EE software starts with the design of the software [3], i.e. with its architecture. Using the SA to determine meaningful units, e.g. architectural elements, can make the software and its context for development easier to understand, control and influence. A similar approach is applied in a wider context for the green performance indicators model [9, 18] containing separate controllable elements on different layers. The relation between these elements shows how ‘green goals’ shine through from top (organizational) level down to the hardware level with software in between. Through software architecture, we propose to unravel the application layer of the model and take a more detailed look into the software itself, i.e. turn software into a ‘white box’.

Different views that map the EC on software artifacts already exist. The node map presented in [11] for example, closely resembles what could be labeled as a deployment view showing the installation of software elements across the available hardware. Analyzing the node map on EC provides a so-called ‘heat map’ of the system. Following this same line, [16] presents the ‘\(ME^{3}SA\)’ model in which again the deployment and functional components of the software are investigated. In relation to green software, a limitation of both approaches is that most recommendations relate to hardware aspects and only provide ‘strong clues’ on software level.

For embedded software, software that accompanies an appliance [36], research on EC also adopts an architectural approach. In [37] a method is presented to determine the minimum EC path through Petri Nets and reachable state graphs. Others propose to create modular software and collect utilization data of functional elements which is used by a resource utilization model [35] functioning as ‘energy broker’. An approach that has recently also been applied to software in general [27]. Although embedded software is often less complex compared to product software, due to its specific, limited functionality for the appliance, a modular approach, which resembles an AD, helps to better understand its energy consuming behavior. Similar to product software, a multiplying effect could also be achieved with embedded software.

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].

Unless (sub)characteristics can be directly measured, the measurable properties of a system (quality properties) can be quantified using quality measures and measure elements. Following the framework of the ISO 25010 standard consider the example in Fig. 2, where the ‘sustainability’ characteristic is broken down to the level of quality measure elements for the ‘workload energy’ property. To quantify ‘workload energy’, the task energy consumption quality measure was identified along with three quality measure elements for the measurement function.

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. As the list is a starting point and by no means definitive, it could be changed or extended based on new insights.

Starting with software utilization we argue that the knowledge gained from performance research can be re-utilized, which is reflected through the fact that the presented measures (CPUU, MU, NT and DT) are common performance metrics providing insight into the behavior of hardware components. Compared to pure performance metrics however, the presented measures are explicitly related to software. Since our focus is on adjusting the software to become more sustainable, it is essential to know how the hardware is stressed under conditions dictated by the software.

Quality measures directly related to EC are described under the energy usage and workload energy properties. SEC is the most basic means of relating EC to software, i.e. measuring the total EC and subtracting the EC while idle. The measure closely resembles ‘annual component consumption (ACC)’ [16], without the inclusion of a specific time frame. The remaining properties, UEC and RUEC, can be derived using SEC and relate EC to a specific unit, e.g. separate elements or combinations thereof. UEC is a measure to allocate a portion of SEC to a defined unit and requires detailed performance data. RUEC puts the EC of a defined unit in perspective of the entire software instance and can be used to quickly identify outliers in EC.

Using SEC and UEC, also TEC and UTEC can be calculated provided that the stakeholder is able to define a task and knows the number of times this task is performed during a measurement. TEC provides insight in the EC to perform a specific task across units (e.g. functional elements) whereas UTEC considers the EC within the limits of a defined unit. If UTEC is related to a specific software component, the measure corresponds to the ‘component consumption per unit of work (CCUW)’ [16].

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.

In relation to the other QAs, the possibility exits that trade-offs have to be made when conflicting goals arise. For example, keeping a log to maintain non-repudiation (security) could negatively affect the TEC of a software product. Making trade-offs however, should not be considered as an inhibiting factor. By making EC explicit, this aspect can be structurally included in a trade-off analysis. Rather than sustainability as an optional goal, a stakeholder can make a shift towards structurally relating sustainability to software products, i.e. sustainability by design. Although our research is focused on the application level, adjustments on a different level (i.e. infrastructure and middleware [9]) could turn out to be more appropriate.

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). Making trade-offs becomes more dynamic when service level agreements are in place. To minimize the total cost of ownership, software vendors and hosting parties strive for the lowest possible EC while still meeting agreements with customers. Effective resource management is essential to manage these environments [1].

To characterize the different views within an AD, views are grouped into viewpoints that focus on similar aspects within the design. Together, these viewpoints define the viewpoint catalog consisting of seven viewpoints (Fig. 3) [31] that can be used to create an AD of the software product focusing on different aspects of the system. Each of the viewpoints defines concerns of a stakeholder, such as requirements, objectives, intentions and aspirations, that the views following that viewpoint should address.

The system design is reflected in the functional viewpoint, the information viewpoint, and the concurrency viewpoint which focus on respectively the product’s functionality, data aspect and the runtime. The deployment viewpoint defines the runtime environment for the software, complemented by the operational viewpoint defining the operation of the software when deployed. Implementation constraints for the software are defined in the development viewpoint. Finally, the context viewpoint defines economic and social aspects of EC in relation to the software design.

To develop an architectural perspective on EC, we address each of the viewpoints and explain how EC affects the viewpoint. For each viewpoint a key question is formulated, that addresses the insight that a viewpoint should provide in relation to EC. As these views cannot be seen in isolation, their consistency and interdependencies, as portrayed in the flow of the key questions (Fig. 3), are crucial. Although we acknowledge that not all viewpoints are required for each concern, given the novelty of the perspective all viewpoints are explained.

Context viewpoint Views in the context viewpoint focus on the environment of the software product, such as business drivers. The experience of the authors in the Dutch software industry is that increasingly more organizations have sustainability in their mission statement. As a consequence, customers of the software industry add sustainability, among others EC, demands to their tenders. This demand is twofold. On the one hand, there is an increased call for software to be developed in a sustainable manner, on the other hand there is the focus on EC of the software product itself. Thus, the contextual view should focus on answering how the software product can help in achieving an organizational sustainability strategy.

One way to contextualize a sustainability strategy is to portray it as strategic goals that should be met. For example, energy efficient software, does not only contribute to sustainability goals, it also provides a means to lower the total cost of ownership for a software product, i.e. it influences the economic aspects (cf. [4]).

In our case study (DG), a lower total costs of ownership enables the software vendor to be more competitive in terms of pricing, and helps in realizing sustainability targets like reducing carbon emissions. In terms of the quality measures (Table 1), a reduction of SEC or UEC indicates a lower power consumption and thus reduced carbon emission (not to mention the energy costs).

Open image in new window

Operational viewpoint The operational viewpoint focuses on how the software is executed, and is where the quality measure elements (Table 1) are measured. Changes from this viewpoint are often system-wide strategies that address operational concerns. Thus a first step to improve the EC, from this viewpoint, is to fine-tune the hardware configuration.

However, as software products typically run on diverse platforms, the architect should specify in this viewpoint which elements are to be recorded and how these elements can be combined into the different measure elements. This leads to a second key question in the operational viewpoint:

For DG, in our limited scope, the architect specified to focus on the CPUU of the ‘Interface.exe’, ‘Connector.exe’ and ‘Document.exe’ processes which were executed on the same server. If the database had been within scope, MU and DT would have been added to the list for the database processes.

Deployment viewpoint The deployment view portrays the actual hardware environment of the software in terms of the processing nodes, data storage nodes and the network topology of how these nodes are connected. Whereas in the operational viewpoint the focus is on the complete system, the deployment viewpoint assists the architect in relating the measures to the individual processes. Knowing which processes run on what hardware provides the architect with valuable insights where (EC) measurements should be performed. This aspect directly gives the key question the deployment viewpoint should address:

For example, DG can be deployed on multiple servers: one data storage server and one or more processing nodes that each run parts of the application. Once the architect creates a mapping between the individual processes (in this case, the executables) to the different hardware nodes, the measures can be assigned and related to the different components DG consists of.

Concurrency viewpoint The concurrency viewpoint shows how functional elements map onto concurrency units, e.g. processes and threads, and forms the bridge between functional elements and their deployment. Hence, the first key question is directly related to this insight:

Additionally, in this viewpoint, the parts of the system are identified that can be executed concurrently. Concurrent processes potentially add to a reduced EC by means of performance efficiency, depending on the coordination and control mechanism required to do so. Again, like the operational viewpoint, a second key question can be formulated:

To calculate UEC for the ‘connector’ element of DG, the concurrency view shows the processes that comprise this element and thus should be considered for their resource consumption. By relating this mapping to the deployment viewpoint (key question 4) we can distill the hardware that should be monitored.

Functional viewpoint The functional viewpoint is part of the system design itself. It defines the elements of which the software is composed and the functions and features these elements offer. This viewpoint is essential to define the boundaries of a software product and identify the separate elements (and functions) of which the energy consumption is of interest. Ideally, after measurements have been performed, the view would include an indication of the EC per element:

The DG workflow (Fig. 1) is executed by three functional elements; ‘composer’, ‘connector’ and ‘generator’. If an EC figure can be assigned to these elements, despite their deployment, a stakeholder can direct efforts to reduce the EC to where they are needed most. In the case of DG, regardless of deployment, one question of interest is “How much energy does the generation of one document cost?”. As multiple elements are involved in this task, EE solutions can be directed to those functional elements that stand out in terms of EC,

Information viewpoint In the information viewpoint, the information is identified that is used by and communicated between functional elements. From an EC perspective, and efficiency in general, it is essential to have the right information on the right place at the right time:

For DG, critical data sections can be identified that might affect the processes in terms of efficiency. If, for example, the data is locked to show a preview, replicating the data could prevent the process from coming to a complete standstill. Of course, in this case, other measures should be introduced to solve any conflicts that might arise.

Development viewpoint The development viewpoint is a starting point to support the development process and contains aspects of interest to those stakeholders involved in building the system. An overview of elements, for example, simplifies the context for developers and prevents them from having to cope with the complexity of the entire application. A developer is facilitated to focus on the code that drives the EC.

In the case of DG, the EC of the ‘connector’ element could be found disproportional. A proper AD could simplify the context for developers tackling the issue.

Open image in new window

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 relation to EC, there is still work to be done to find a set of tactics that are able to satisfy the concerns. Consequently, the presented tactics are by no means a definitive list but should be considered as a source of inspiration for green software efforts.

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. Even though the tactics are explained specifically in a cloud computing context, they could prove valuable for software in general.

Increase modularity 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. This tactic holds under the assumption that the increased disk usage has a marginal impact on the EC figures.

Network load optimization 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. Although difficult to quantify in terms of EC, a positive effect is expected when the communication load is reduced.

Increase hardware utilization [11] 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. Variations in deployment imply that the software is able to cope with variation and thereby could impose redesigning the software.

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. Further investigation is required to test the generalizability of this finding, but the tactic could prove useful for individual software instances.

Open image in new window

With regard to the validity of the case study, an evaluation is performed following the threats as identified in [32].

The construct validity considers whether the correct measures were identified for the object under study. In Sect. 3 we introduced sustainability as a QA and unraveled this attribute to low level quality measures related to EC. During this process we followed existing literature on both EC measurements and performance research to operationalize the quality measures in terms of being able to perform measurements. The resulting breakdown is similar to others in this field of research, where performance measurements are used to relate EC to the software or elements thereof.

In light of the internal validity, despite careful preparations, due to the behavior of services we can not be 100 % certain that DG was solely responsible for the load on the test server. Therefore each individual measurement was checked for such processes using performance data. Also, due to time constraints, we could not balance the number of measurements between creating the energy profile and evaluating the redesign. At the start of the case study we lacked experience with configuring DG, e.g. we experienced firewall issues, resulting in a lower number of measurements. During evaluation we were more familiar with the case and relatively more valid measurements were obtained.

A threat to the external validity is the fact that the case study was performed in a separate test environment containing specific hardware. Given the relation between hardware and EC, different hardware could provide different findings. Although the EC figures could differ in absolute terms, since an actual commercial software product was used and installed according to production standards, we argue that the results are not specific to our environment.

Finally, reliability is concerned with the results, data and data analysis being dependent on specific researchers; i.e. replicating the case study under similar conditions should yield similar results. To this end the measurements within the case study were performed by following a strict, openly described protocol. A difference could occur with the statistical analysis of the data since, given the nature of the data, we decided to process the data ‘as is’ where others might prefer to normalize the data.