In September 2022, we did a 2-day IT-internal Hackathon at the company I work for. The focus was on sustainability and how we as IT could drive this forward to make our own processes more energy efficient or come up with ideas which could be applied outside of IT for the whole company. For the Hackathon, we worked on 15+ suggested topics in teams ranging from 2 to 10 people. Teams were for example working on tools to improve planning for our cafeteria, on sharing rides to and from the office or how to share knowledge more efficiently - to name just three.
Last year, we also started an internal activity dubbed "Green-IT" which has since then evolved into a small and dedicated "guild" as we call such cross-process teams. We meet every couple of weeks, to plan what to tackle next and recently helped to pull-off a "data clean-up" day to get rid of no longer needed data. The examples given below are now also tackled under the Green-IT umbrella.
Together with a colleague, I tackled the "mundane" topic to eliminate performance hogs from our SAP-system and to identify background jobs which generated an inordinate amount of spool-output on a regular basis during the Hackathon. For the performance issues, we documented an extreme case which I had already resolved before the Hackathon, but it was such a "good" example that we just had to include it and the staggering numbers of improving the average runtime of a program from 27 hours to 15 seconds. You can read about that task in an earlier of my blog posts.
Making this program run faster was obviously much appreciated by the end-users relying on the data but it also had a noticable effect on the energy used and CO2e emissions caused by running the program on an almost daily basis. We used the website Green Algorithms to do a rough and ready calculation based on some assumptions for one-year worth of running the program.
This is how this looked like before the changes, causing almost 770kg of CO2-equivalent emissions and needing 2.27 MWh of energy:
These numbers plummeted to just 119g of CO2e and 350 Wh respectively, again calculated for the whole year.
Source: Green Algorithms
Next steps will be to find and eliminate more of these performance hogs.
Another issue is, that there are unfortunately quite a lot of jobs, which create spool output which more likely than not, nobody ever looks at. At least, that's our incoming assumption for any regularly created spoollist with more than 300 pages (perhaps even less than that).The more pages these spool lists have, the less likely they'll be looked at, I guess! We checked the spool-output in our main SAP-systems and found that in the span of 10 days, more than 1,000 jobs had generated more than 1,7M output pages! Just imagine how many trees would have needed to be cut down, had all of these pages been sent to a printer instead of just the spool?!?
On the other hand: had all of these pages ended up at a physical printer generating physical output, somebody somewhere would have taken note, wouldn't they? But even with "just" ending up in SP01, storage capacity is most likely taken up unnecessarily, not to mention the runtime and effort and energy expended on those. It'll be an ongoing taks to sift through these lists repeatedly and to identify who actually needs the results (if anybody does) and what can simply be stopped - or at least no longer be generated.
So, these are my examples for Arbor Week - what are yours?
To learn more, please check the blog post Arbor Week Celebration (April 24 – 28, 2023) published by l_stodal on April 6 and look for other content with hashtag #arborday!
Last year, we also started an internal activity dubbed "Green-IT" which has since then evolved into a small and dedicated "guild" as we call such cross-process teams. We meet every couple of weeks, to plan what to tackle next and recently helped to pull-off a "data clean-up" day to get rid of no longer needed data. The examples given below are now also tackled under the Green-IT umbrella.
Performance
Together with a colleague, I tackled the "mundane" topic to eliminate performance hogs from our SAP-system and to identify background jobs which generated an inordinate amount of spool-output on a regular basis during the Hackathon. For the performance issues, we documented an extreme case which I had already resolved before the Hackathon, but it was such a "good" example that we just had to include it and the staggering numbers of improving the average runtime of a program from 27 hours to 15 seconds. You can read about that task in an earlier of my blog posts.
Making this program run faster was obviously much appreciated by the end-users relying on the data but it also had a noticable effect on the energy used and CO2e emissions caused by running the program on an almost daily basis. We used the website Green Algorithms to do a rough and ready calculation based on some assumptions for one-year worth of running the program.
This is how this looked like before the changes, causing almost 770kg of CO2-equivalent emissions and needing 2.27 MWh of energy:
These numbers plummeted to just 119g of CO2e and 350 Wh respectively, again calculated for the whole year.
Source: Green AlgorithmsNext steps will be to find and eliminate more of these performance hogs.
Spool-Output
Another issue is, that there are unfortunately quite a lot of jobs, which create spool output which more likely than not, nobody ever looks at. At least, that's our incoming assumption for any regularly created spoollist with more than 300 pages (perhaps even less than that).The more pages these spool lists have, the less likely they'll be looked at, I guess! We checked the spool-output in our main SAP-systems and found that in the span of 10 days, more than 1,000 jobs had generated more than 1,7M output pages! Just imagine how many trees would have needed to be cut down, had all of these pages been sent to a printer instead of just the spool?!?
On the other hand: had all of these pages ended up at a physical printer generating physical output, somebody somewhere would have taken note, wouldn't they? But even with "just" ending up in SP01, storage capacity is most likely taken up unnecessarily, not to mention the runtime and effort and energy expended on those. It'll be an ongoing taks to sift through these lists repeatedly and to identify who actually needs the results (if anybody does) and what can simply be stopped - or at least no longer be generated.
So, these are my examples for Arbor Week - what are yours?
To learn more, please check the blog post Arbor Week Celebration (April 24 – 28, 2023) published by l_stodal on April 6 and look for other content with hashtag #arborday!
- SAP Managed Tags:
2 Comments
