A common way to address the consequences of design decisions on a QA is via an architectural perspective, which is ‘a collection of activities, tactics, and guidelines that are used to ensure that a system exhibits a particular set of related quality properties that require consideration across a number of the systems architectural views’ [31]. Perspectives are a means to systematize the tasks of an architect, e.g. identify, test, and select architectural tactics to address cases when the architecture is lacking, and provide a framework to guide and formalize the process.
In this section we present the EC perspective including the applicability to views (including concerns), activities and tactics, following the detailed format presented by Rozanski and Woods [31]. As it is not possible to provide an exhausting set of guidelines, we recommend similar research (e.g. [11, 16, 27]) as guidance.
Viewpoint catalog
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.
Key Question 1
How can the software product architecture assist in achieving an organization’s 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).
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.
Key Question 2
How can run-time aspects be fine-tuned to reduce EC?
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:
Key Question 3
How can we measure the EC of the different nodes the software is executed on?
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:
Key Question 4
Which processes run on what hardware?
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:
Key Question 5
How do the functional elements map onto processes?
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:
Key Question 6
What processes can be executed concurrently without increasing the resource consumption related to their coordination and control?
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:
Key Question 7
How much energy does each function consume?
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:
Key Question 8
How can the information flow be optimized to increase EE?
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.
Key Question 9
What green algorithms can be applied to the software and where should they be applied?
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.
Perspective activities
Following [31], we provide a set of activities (Fig. 4) to apply the EC perspective. By applying the perspective a stakeholder has a means to analyze and validate the qualities of an architecture and drive further architectural decision making. The activities follow a ‘Plan-Do-Check-Act’ cycle where the iterations are focused on whether the software meets certain requirements.
-
1.
Capture energy requirements Requirements form the basis for change in relation to SA [2] and should be considered when strategical, economical or customer motives are present. Energy requirements can be formulated like other requirements, however it might prove difficult to translate the requirements into quantitative goals. Cross-checking the goals with stakeholders is essential to ensure the software will fulfill the requirements.
-
2.
Create energy profile An energy profile of the software provides the stakeholder with an objective starting point and benchmark to identify ‘’hot spots’ and determine whether the desired results have been achieved. Creating the profile requires EC and performance measurements and can be visualized by creating an overlay for the AD, e.g. Fig. 7 is annotated with EC figures for the generator element. Mind that profiling an application could be time-consuming where a profile for the elements within the scope of current requirements could be sufficient.
-
3.
Assess against requirements Using the energy profile an assessment should be performed on whether the software meets the requirements. i.e. whether the quantified goals are met. If requirements are not met, the assessment should show what quantitative goals are not met and the (software) aspects that are directly related to these goals. Ideally this activity should be performed periodically or, more specifically, when the application has changed.
-
4.
Determine adjustments If required, adjustments should be determined to meet the requirements. Tactics (see Sect. 4.3), patterns and other known solutions should be considered that affect specific ‘hot spots’ signaled by the quality measures. To guide the selection process for selecting the right adjustments, a business case should be created projecting the expected costs (e.g. development time and costs) and benefits (i.e. EC savings over time). Since the area of green tactics is still relatively immature, the perspective can also be used to investigate the consequences of tactics. Using the AD, and relevant viewpoints, stakeholders can identify and control possible (unwanted) effects on related architectural elements.
-
5.
Apply adjustments Applying the adjustments depends on the nature of the adjustments. Adjustments related to the infrastructure, for example, can be applied on-the-fly by an administrator with little effort. Redesigning, or even adjusting, the software on the other hand, often requires development resources and capacity planning upfront. The resources required to apply an adjustments should be included accordingly in the business case for the adjustment.
-
6.
Evaluate adjustments Last is determining whether requirements are met and assuring no unwanted effects are brought about. Evaluation requires the stakeholder to perform measurements in the newly created situation and compare the figures against the benchmark (i.e. the energy profile). A stakeholder should give a statement on whether the adjustments are satisfactory.
Green architectural tactics
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.