Are you ready for carbon reporting, and for your digital footprint?

Set out in article L. 229-25 of the French Environment Code, the greenhouse gas emissions report (BEGES) is a regulatory obligation for all private companies with more than 500 employees and public bodies with more than 250 staff.

From this year onwards, statutory auditors could start raising an eyebrow when approving the accounts of companies that have not committed to an environmentally responsible approach.

Where does your own organisation stand? How, at your level, can you contribute to putting this approach in place, and how can we, as a consultancy, help you do it?

A line of thinking fed by artificial intelligence

Let us say it straight away: this article was not written by Bard, Gemini or ChatGPT. It may even run slightly against the grain of the talk we currently hear from our clients. It was prompted by a single sentence heard during a tender presentation at a mid-sized company.

• Them: "Your solution does not include enough innovation linked to artificial intelligence"

• Us: "What do you expect from it"?

• Them: "Er, we do not really know. But show us what is possible and we will no doubt find some uses for it".

So here we are: the value that will be created is hard to picture. What is easy to picture, on the other hand, is that none of this comes for free. Try installing a GPT on a workstation (if you want to run the test, I recommend privateGPT, which is easy to configure and well documented), load some files and query it while watching resource consumption.

Here is a small example of the impact on the CPU of a document summary request on PrivateGPT (a local generative artificial intelligence solution), run on the same instance as the one used for the tests further down. The server is not built for this, and it uses CPU rather than GPU, but the experiment still shows a high impact for the operation.

Back to the point (an older observation)

The habit of looking for a use for a new feature (and, sadly, of finding one) is not new. For years we have seen a natural tendency towards complexity, and towards "if the feature exists it must be good for something". And for years we have spoken out against it, fairly ineffectively I admit. Except that today its financial and environmental impact can no longer be ignored. Now is the moment to tackle it, all the more so because the arrival of AI will produce a few good ideas and a great many bad ones.

So it is a good idea to start today on the sources of waste hiding in our applications.

Reducing your digital footprint: is there really anything to be done?

At BleuLemon we often see that the digital footprint of a tool is decided not only by the choice of that tool, but by the way it is configured and lived with by the teams. That is the area where we help our clients most: clarifying, simplifying, putting the essentials back at the centre.

When choosing a solution, you can turn to your supplier to find out how it is itself engaged on these questions. How the products are designed, developed and run. But if you already have the tool, what can you do?

The environmental cost of a tool breaks down as follows:

• Its intrinsic impact, which takes into account the way it is designed, and the environmental costs of its development;

• The impact of the infrastructure it runs on. In the case of the Cloud, that is out of your hands. If on the other hand you do control that infrastructure (because the tool runs in your own data centre, or in a private Cloud you have chosen), you can act on the equipment and select more virtuous components (at present AMD is developing GPUs that consume less than Nvidia's, for example).

• The impact of the configuration. That is the area where we can help you act.

That all sounds fine, but does it really have an impact?

To answer that question, we ran an experiment. We installed a recent version of Jira Software on a dedicated server, connected to a Postgres database running on the same server. We put that instance under load by creating 300 requests through the REST API using a script. To avoid any pollution from the execution load of the script itself, the script runs on a third-party server.

In a second stage, we configured a simple automation that multiplies the values of two numeric fields set when the request is created, and stores the result in a third field.

Finally, we developed a Java plugin that performs the same task.

We cannot measure the electricity consumption of the server directly (all the more so because it sits physically in the data centre of a private Cloud provider, which we cannot access). We therefore worked on the assumption that electricity consumption is a function of CPU consumption.

We are measuring CPU usage here in order to infer the impact on consumption.

Zone (1) shows the CPU consumed by the creation of 300 requests, with no particular calculation.

Zone (2) shows the CPU consumed by the creation of 300 requests, together with a listener that multiplies the two numeric values and stores the result in a third field.

Zone (3) shows the CPU consumed by the creation of 300 requests, together with an automation that multiplies the two numeric values and stores the result in a third field.

The intermediate peaks represent the actions involved in deleting the requests created previously (to return to a situation comparable with the other tests), and the configuration operations that enable and disable the plugin and the automation rule.

This kind of analysis shows how far a small feature can weigh down the digital footprint of a tool. At BleuLemon, that is precisely what we observe during our complexity audits.

In conclusion, one very small feature has a high impact on CPU consumption, and therefore on electricity consumption. Depending on how that feature is implemented, it adds +50% or +150%. And the simplest solution is not necessarily the least costly.

Once again, the point is not to say that certain actions should never be automated. The point is to ask, every time: why are we doing this? Is the game worth the candle?

BleuLemon's advice:

Ask yourself what you actually need

It sounds simple. And yet it is not quite so simple. A few examples:

• Sending emails is not a need. Keeping people informed is. In many cases, sending emails achieves the opposite result. And it often leads people to set up automatic rules in their mail client to send those emails straight to the bin, which consumes yet more resources.

• Generating reports is not a need. It is reassuring, but in itself it brings very little. The question to ask is: what decision will this indicator allow me to make? If you do not know, remove it.

• Automating is not a need. Seeking to automate tasks that are necessary, repetitive and predictable in their outcome is commendable. But rather than automating an unnecessary task, remove it.

• Automating a task that is not repetitive can be needlessly costly.

• Automating a task whose outcome is not predictable can lead to disengagement and a loss of trust.

Avoid duplication

The same process should not be implemented in several tools. Doing so multiplies resource consumption.

Side benefits

Because good news never comes alone, and as mentioned above, economy of means brings collateral benefits of its own.

• Better governance: the simpler your instance, the less it risks producing behaviour that no one controls. It is better understood, it evolves more easily, and your administrators spend more time talking to users than debugging how the tools behave.

• More effective onboarding. And if your environment is better understood, it is better explained. Every new joiner will take less time to understand the processes and will be productive sooner.

What can you do?

Supporting this kind of approach, understanding the real footprint, identifying the levers for simplification, restoring clarity, is part of our day-to-day work. At BleuLemon, we work closely with IT departments to build leaner, more stable and more sustainable environments together.

An audit often identifies the invisible rules, inherited or implicit, that contribute heavily to complexity both perceived and real.

Working on the reduction of an instance's digital footprint is not a purely technical matter: it is a question of governance, of control, and of operational stability. If you already use these solutions, and the damage may already be done, there is still some good news. Errare humanum est (sed perseverare diabolicum).

It is never too late. Here is a set of things you could do, and that we have already implemented at client sites.

• A complexity audit: this audit has two dimensions. A technical one and a human one. In a sense, an analysis of real complexity (automations in place, number of objects handled, notification rules, plugins installed, and so on) and an analysis of perceived complexity.

• A list of possible simplification actions. The preliminary analyses will bring out avenues for simplification. For example:

  • Dropping rules that serve no purpose;

  • Removing practices that serve no purpose (unused reporting, for example);

  • Dropping or reducing email exchanges (see this article to better understand what is at stake in reducing email exchanges);

  • and so on.

Internal communication: because when a company does something good, it would be a shame to hide it. And the actions taken within the company may also make some employees more aware of the effect of everyday behaviour on the wider improvement of the environment.

If you want to explore this subject, or get some help, BleuLemon is here to support you.