Sustainability by Design

Why Sustainability by Design? 

Sustainability by Design interfaces with GreenOps. Where GreenOps primarily focuses on the most sustainable infrastructure choices, Sustainability by Design is primarily about the design of the software: how do I build my application to function as energy-efficiently as possible? The two come together in the sub-theme ‘Designing for the cloud’. Robbrecht: “If you build an application yourself and run it locally, you notice right away if it isn’t running well and has bugs. The hourglass shows up a lot, the fan comes on. But if you build an application that runs in the cloud, you can easily add extra capacity at the back end, which means that the need for more resources remains invisible. In the end, the colleagues who are responsible for the infrastructure are presented with a sky-high energy bill. GreenOps allows them to adjust certain parameters they can influence, including the advice to design serverless applications so they can run in the cloud. Sustainability by Design is one step ahead of this.”  

What is covered by Sustainability by Design? 

There are four parameters you can adjust to improve the sustainability of your applications. 

1. Life cycle management 

The first question you need to ask yourself is: do I really need this functionality? Because functionality that isn’t built won’t use any energy. Robbrecht: “If you’re doing it right, you already ask the question of what you really need as part of life cycle management (LCM). From now on, in LCM, look at your software through an energy lens: what functionality can you turn off? Where do you need to do maintenance? Et cetera.” 

Be especially critical of energy-intensive services where AI is often running in the background. “You need to clearly understand that cloud suppliers’ business models are aimed at increasing usage of their services,” says Robbrecht. “The default settings of their software are not usually the most energy-efficient settings. My dishwasher is set so that if I don’t consciously choose a different programme, it automatically selects eco mode. With a lot of cloud software, it’s exactly the other way around.”  

Robbrecht thinks that cloud providers will make different configuration choices if public organisations include energy efficiency in their European tenders. “That can function as a lever for the whole market. Now, in their procurement, government organisations say that suppliers have to use green electricity and offset their emissions. But it doesn’t say anything about reducing power consumption. If that does become a selection criterion, suppliers will start modifying their products, and other customers will also benefit from that.” 

2. Not everything needs to be updated 

If you decide to use AI, you will need to keep your models up-to-date to prevent the outcomes gradually becoming inaccurate (also known as model drift). This is why many governance protocols say that models should be retrained every month or quarter. “But of course that really isn’t necessary if you know that there have barely been any changes in the datasets used,” says Robbrecht. This not only saves time, but also energy, because training models is a particularly energy-intensive process.  

You can also look more critically at the topicality of the data you use. Robbrecht: “For example, we found that the software used by banks to implement the Money Laundering and Terrorist Financing (Prevention) Act (Wwft) requests a Chamber of Commerce extract in every audit by default, without checking whether this extract has been requested recently. We modified the software so it checks whether the data needed is still in the cache first.” 

3. Development language

Low-level languages like Java or C++ are much harder to learn because they require knowledge of architecture and coding principles. But because they are closer to machine language, they work much more efficiently than high-level languages like JavaScript, Python or the code you generate with low-code development platforms. “I like to make the comparison with fast fashion,” says Robbrecht. “The easier a language is, the less efficient the implementation is because you can’t do specific optimisation. Because it’s so easy, you’re more likely to develop software for a certain task and then discard it more quickly.  

That’s fine for specific cases, of course, like a short-term marketing campaign where an application is running in the background. But for processes that don’t change quickly, it’s better to write the code for the supporting software as efficiently as possible.”  

Although he primarily advocates for more training to learn low-level languages, and especially coding principles, he also advises: “Use generative AI to write code. Because AI generally writes more efficient software than developers themselves.” He gives the example of a complex query. “Humans will write the code to break down a complex query into all the small individual queries, and then merge the results. That means the database has to be queried very often. AI writes the query so the database only needs to be queried once.” 

4. Cloud computing 

Finally, like Jeroen Timmermans and Marcel Stangenberger, Robbrecht points to the importance of cooperation between different areas of expertise. “When you develop software using the CI/CD method, administrators, infrastructure specialists and developers have to interact with each other. This makes them more likely to develop supply chains that function efficiently as a whole.” You might often choose the cloud, but the cloud also adds capacity without you really noticing. “How do you reap the benefits of one while minimising the impact of the other? These are issues you really need to look at together,” says Robbrecht. The same applies to test environments. They often contain much less data than production environments, which means developers do not get a good picture of the energy efficiency of their application. Robbrecht concludes: “Get out of your bubble, work together, and look at this issue broadly.”