Principles and Rules for a Sustainable Software Service Design

The cover story of the February issue of the German JavaMagazin is about Sustainable Service Design1, which means, of course, sustainable service design in the Java universe. The article by Wolfgang Pleus is presented as the introduction to a series of articles. He shortly discusses the meaning of sustainability and sustainable development as one basic concept of modern business operations, i.e. of software development corporations. Thereafter, he presents his basic concepts and rules that enable a software implemented service to be sustainable. The next article in this series of the JavaMagazin will focus on concrete implementations of the sustainable design principles in the Java ecosystem. The cover story is appended by an article where the author is interviewed about how microservices and his sustainable design principles complement each other2.

The article is, to my knowledge, the first article published in a popular German mainstream programmers magazine that is concerned with sustainability in software and which proposes concepts immediately usable by practitioners.

Unfortunately, Mr. Pleus does not dive with the necessary depth into the field of sustainable software, neither in his article nor in the interview. Ecological sustainability appears only in the first question of the interview (literally translated from the German original):
“JavaMagazin: If I act ecologically sustainable, I have, primarily, restricted raw materials and the coming generations in mind. For whom or what should a software architect feel responsible to design a sustainable system?”2:40
In his answer, Mr. Pleus does not even catch the given catchword “ecologically sustainable”:
“Wolfgang Pleus: For the success of the company for which he or she works. Or [...] for the success of the product on which he works. Today and tomorrow.”2:40
Regarding the ongoing research and discussion of the scientific community as well as the interested public in the area of sustainable ICT, which naturally includes also software, the answer of Mr. Pleus is entirely superficial and shockingly simple-minded. It looks as if the long lasting economic success of the employer is the only aspect that should matter for software architects. This is particularly the more annoying because the magazine suggests with its explicit green front-cover design that the cover story is also about ecological sustainability.

However, despite these shortcomings in the article and in the interview, sustainable business strategies should find a balance between economic, ecological, and social aspects of sustainability, or, to be more precise, Sustainable Development. Additionally, many economically founded aspects can also be interpreted from an ecological point of view.

Hence, here comes a condensed summary of the four basic principles for a Sustainable Service Design, which we will examine for ecological sustainability aspects in the Discussion section later on:
  1. Define your service as a reusable and platform independent concept rather than sticking on implementation details of a specific service or transport technology.1:34
  2. Define separate request and response messages to communicate with your service.1:34
  3. Lay down the contracts of your service before writing the very first line of code (Contract First approach). Describe the request and response messages in a standardized and technology neutral language (e.g. XSD). Describe the operations of your service with the means of implementation free programming language constructs1:34–6 (e.g. interfaces in Java and C# or classes containing only pure virtual methods in C++).
  4. Bind concrete protocol implementations (e.g. SOAP, JAX-WS, etc.) to your service implementation by using only the message types and operational interfaces defined by the contract.1:36–7
These four principles are further refined by ten rules for service contracts of sustainable service designs1:37 (also just a summary).
A service should...
  • … represent an easily understandable concept to ease reuse.
  • … be potentially reusable.
  • … have an increased level of abstraction to allow reuse.
  • … provide mass operations.
  • … provide compensation mechanisms to undo previously executed operations.
  • … provide correlation mechanisms to enable clients to correlate responses with requests.
  • … provide information and meta information about data it manages, stores, or uses.
  • … provide meta information of a classification system in order to facilitate its findability and thus reuse.
  • … provide a complete documentation of its service contracts.
  • … provide meta information regarding the available protocol bindings and its service, but also a contact.


As can be seen from the principles and rules, Sustainable Service Design designs services for reusability, long usage times (due to the usage of standards), easy adaptability to new state of the art or even hyped protocols, and a minimum of support efforts (due to the self-contained documentation). It is also clear that longer usage times and a good modifiability (adaptability) have a positive impact on the client-side, because it is possible to provide old fashioned protocol bindings alongside with state of the art protocol bindings, which prolongs the usage time of old-fashioned clients and eliminates the necessity to migrate to modern protocol stacks.

In 2004, Albertao3:5–6, 4 interpreted common quality properties of software regarding their impact on Sustainable Development, including economical but also social and ecological aspects. From his work, I picked some ecological interpretations that are also true for sustainable software services:
  • A higher Reusability causes less development efforts in future projects and thus causes less energy demand and carbon dioxide emissions for operating the IT infrastructure and for heating or air-conditioning the premises.
  • A better Modifiability causes less environmental waste/releases less emissions to the atmosphere through less efforts in manufacturing and maintaining the system.
  • A good Portability helps in minimizing e-waste by extending the lifetime of older hardware. Here, not only the server part is of interest, but also the client part, where it is with the principles and rules of a Sustainable Service Design easily possible to provide legacy and modern protocol bindings in parallel.
  • A higher Supportability (remember the self-contained documentation mentioned in the service contract rules) minimizes the resources necessary to provide support services to implementers of client software. Furthermore, a good documentation may also speed up development time. Both lead to less energy demand during development and maintenance and thus less greenhouse gas emissions.
The ecological benefits arising from the quality properties are hard to measure or to estimate, but this is also true for the economic benefits. However, in environmental sciences, it is widely accepted to “proof” made assertions with measurements or approximations of real world projects. To my knowledge such a “proof” that hardens the general validity of Albertao’s interpretations does not exist.

Another aspect one should keep in mind is that according to popular definitions of sustainable software it is not sufficient to simply design software to be more sustainable. It is rather additionally necessary to manufacture and maintain it in a sustainable way5, 6 (see also posts “What is Sustainable Software?”, “Sustainable Software Processes, Episode 2: Green Software Engineering with Agile Methods”, and “Effects of Information and Communication Technology on Sustainable Development”). Hence, applying the principles and rules of a Sustainable Service Design does not automatically mean that the resulting software can be called Sustainable Software, because Sustainable Software is much more than just designing and coding stuff. At most, Sustainable Service Design contributes its principles and rules as best practice to the designers and developers who are working on sustainable software.

The quality properties Reusability, Modifiability, Portability, and Supportability increase the efficiency of the development, maintenance, and support teams. This means that the teams can finish more work in the same amount of time, which means also that the environmental waste and the emissions to the atmosphere per project or product decrease. However, the total amount of waste and emissions remains the same (as long as we do not fire any employees and reduce rented office space; firing employees certainly has a negative impact on social sustainability). This shows that an increased efficiency does not necessarily mean that the negative environmental impacts are smaller. With this knowledge in mind, is it valid to assert that a more efficient product or service is more sustainable? Probably not. Currently the discussions in science and academia on this topic are still going on7.

In my opinion it is not valid to call an optimized software, whether it is optimized regarding its coding in sense of energy efficiency (similar to runtime efficiency) or whether its design increases the efficiency of the involved teams, a Sustainable Software without continuously optimizing the negative impacts of your whole corporation, including all other projects and products, the IT infrastructure, premises, business trips, etc. Nevertheless, in the software branch, we can solve many directly observable negative impacts on environmental sustainability simply by switching from conventional to renewable energy sources for electricity and heating. Additionally, we can purchase IT infrastructure that claims to fulfill the requirements of environmental labels, e.g. the ENERGY STAR (http://www.energystar.gov/ or the EU Eco Label (http://www.eu-ecolabel.de/).

Beyond the easily observable direct effects exist indirect effects and systemic effects. Indirect effects result from using ICTs and may change other products, services, and processes. Systemic effects are long-term effects and result from adaptive reactions of societies to the availability of ICT-based services and products, e.g. structural changes in societies or changes in people's lifestyle8:194–5, 9:147. Effects and impacts on Sustainable Development of these two categories are very complex and therefore hard to examine. Nevertheless, regarding the chances of ICTs to master the manifold challenges of Sustainable Development, indirect effects and system effects are much more important than optimizing the efficiency of program code or business processes. If this has piqued your interest in those matters, just take a look in the open-access proceedings of the international conferences ICT for Sustainability (ICT4S, http://ict4s.org/):

In conclusion, I presented Mr. Pleus principles and rules for a Sustainable Service Design in this post. In addition to Mr. Pleus findings, which are only concerned with aspects of an economical sustainability, I presented and shortly discussed some interpretations from an ecological point of view. Although a general proof of these ecological interpretations is missing, Mr. Pleus Sustainable Service Design should be best practice for designers and developers of sustainable software products.

  1. Pleus, W.: Sustainable Service Design. Nachhaltige Softwareservices - Teil 1: Grundlagen. Java-Magazin, issue 2, pp. 31–37 (2015)
  2. Kupfer, D.: Wolfgang Pleus im Interview: Microservices und Sustainable Service Design ergänzen sich gut. Java-Magazin, issue 2, pp. 40–41 (2015). http://jaxenter.de/artikel/microservices-sustainable-service-design-178276
  3. Albertao, F.: Sustainable Software Engineering. http://www.scribd.com/doc/5507536/Sustainable-Software-Engineering#about, 2014-10-24
  4. Albertao, F., Xiao, J., Tian, C., Lu, Y., Zhang, K.Q., Liu, C.: Measuring the Sustainability Performance of Software Projects. In: IEEE Computer Society (ed.): 2010 IEEE 7th International Conference on e-Business Engineering (ICEBE 2010), Shanghai, China, pp. 369–373 (2010). doi:10.1109/ICEBE.2010.26
  5. Naumann, S., Dick, M., Kern, E., Johann, T.: The GREENSOFT Model: A Reference Model for Green and Sustainable Software and its Engineering. SUSCOM, volume 1, issue 4, pp. 294–304 (2011). doi:10.1016/j.suscom.2011.06.004
  6. Lami, G., Fabbrini, F., Fusani, M.: Software Sustainability from a Process-Centric Perspective. Systems, Software and Services Process Improvement. In: Winkler, D., O’Connor, R.V., Messnarz, R. (eds.): Systems, Software and Services Process Improvement. 19th European Conference, EuroSPI 2012, Vienna, Austria, June 25-27, 2012. Proceedings. Communications in Computer and Information Science, volume 301, pp. 97–108. Springer, Berlin, Heidelberg (2012). doi:10.1007/978-3-642-31199-4_9
  7. Hilty, L.M.: Why energy efficiency is not sufficient - some remarks on "Green by IT". In: Arndt, H.-K., Knetsch, G., Pillmann, W. (eds.): Man • Environment • Bauhaus, Light up the Ideas of Environmental Informatics. Part 1: Core Application Areas. Proceedings of the 26th International Conference on Informatics - Informatics for Environmental Protection, Sustainable Development and Risk Management, pp. 13–20. Shaker Verlag (2012)
  8. OECD Information Technology Outlook 2010. OECD Publishing, Paris (2010). http://www.oecd.org/sti/ito
  9. Hilty, L.M.: Information technology and sustainability. Essays on the relationship between ICT and sustainable development. Books on Demand, Norderstedt (2008)