pith. sign in

arxiv: 2604.09278 · v1 · submitted 2026-04-10 · 💻 cs.SE

Toward an Architectural Blueprint to Observe Sustainability in and by Software Systems

Klervie Tocz\'e , Andrei Dragomir , Vincenzo Stoico , Patricia Lago This is my paper

Pith reviewed 2026-05-10 17:35 UTC · model grok-4.3

classification 💻 cs.SE
keywords sustainabilityobservabilitysoftware systemsarchitectural blueprintenergy consumptiondeployment codesoftware architecture
0
0 comments X

The pith

An architectural blueprint with deployment code lets teams add observability for software sustainability, including energy use.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper puts forward an architectural blueprint and its associated code to make it simpler to incorporate observability into software systems, especially for sustainability dimensions such as energy consumption. This addresses the barrier that adding such capabilities usually demands technical expertise not present in every project. A sympathetic reader would see value in enabling more teams to spot issues and pursue improvements in how software affects sustainability. The blueprint helps define required components for specific situations and organizes how they should be deployed, with illustrations from two use cases.

Core claim

We propose an architectural blueprint along with its deployment code that can be used to facilitate the addition of observability in software systems. As a special case, it includes measuring the energy consumption of software. This toolkit provides support in defining which components are necessary for a given use case and for structuring their deployment. Moreover, we exemplify the addition of observability in two different use cases.

What carries the argument

The architectural blueprint, which specifies necessary components for observability and structures their deployment in software systems.

If this is right

  • Teams gain a structured way to define and deploy observability components for sustainability tracking.
  • Energy consumption becomes measurable as part of routine system monitoring.
  • Software issues tied to sustainability can be identified more readily through added observability.
  • Improvements to reduce environmental impact can be guided by concrete observations from the system.
  • The same blueprint structure can be reused across varied use cases as shown in the examples.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Wider use of the blueprint could encourage consistent practices for tracking software's environmental effects across projects.
  • The approach might extend naturally to additional sustainability metrics beyond energy once the core structure is in place.
  • Integration with existing monitoring tools could lower the effort needed for initial adoption.
  • Over time, collected data from multiple systems might reveal patterns in how software design choices affect sustainability.

Load-bearing premise

That providing a general architectural blueprint and deployment code will enable teams lacking technical knowledge to successfully add and apply sustainability observability in their own systems.

What would settle it

A test in which development teams without observability expertise attempt to follow the blueprint and code to implement energy-consumption monitoring and report whether they succeed in producing usable measurements.

Figures

Figures reproduced from arXiv: 2604.09278 by Andrei Dragomir, Klervie Tocz\'e, Patricia Lago, Vincenzo Stoico.

Figure 1
Figure 1. Figure 1: Architectural Blueprint [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: The Feed4Food stack agriculture setups called Living Labs (LL) that are developing urban gardens with a common goal (sustainable, inclusive and healthy urban food environments) but in different contexts (e.g., size, location, and type of LL gardeners). Most of the data collected in this project comes from humans (e.g., harvest, irrigation, event attendance) and some can be collected by software measurement… view at source ↗
read the original abstract

Enabling observability in software systems brings many benefits. It can, for example, ease the identification of issues or the implementation of improvements. It is especially critical to be able to observe sustainability-related dimensions of systems to know and mitigate their impact. However, adding observability to a system, especially related to software sustainability, requires technical knowledge that may not be available in every project that would benefit from it. In this work, we propose an architectural blueprint along with its deployment code that can be used to facilitate the addition of observability in software systems. As a special case, it includes measuring the energy consumption of software. This toolkit provides support in defining which components are necessary for a given use case and for structuring their deployment. Moreover, we exemplify the addition of observability in two different use cases.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 1 minor

Summary. The paper proposes an architectural blueprint accompanied by deployment code to facilitate the addition of observability features to software systems, with a special emphasis on sustainability dimensions such as energy consumption measurement. The blueprint is intended to help teams lacking specialized technical knowledge by guiding component selection and deployment structure, and the contribution is illustrated via two use-case examples.

Significance. If the blueprint were shown to enable non-expert teams to successfully implement sustainability observability, it would offer a practical contribution toward more accountable software systems. The inclusion of deployable code is a strength that supports potential reproducibility and adoption.

major comments (1)
  1. Abstract: The claim that the toolkit 'can be used to facilitate the addition of observability in software systems' for projects where 'technical knowledge that may not be available' is load-bearing for the stated contribution but is supported only by the description of the blueprint and two author-led use cases; no usability evaluation, third-party deployment data, or metrics on required prior expertise are reported, leaving the 'facilitates' assertion as an untested assumption about transferability.
minor comments (1)
  1. The manuscript would benefit from explicit positioning against related observability frameworks (e.g., OpenTelemetry) to clarify the novelty of the proposed blueprint.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive feedback. We address the major comment below and will revise the manuscript accordingly.

read point-by-point responses

  1. Referee: Abstract: The claim that the toolkit 'can be used to facilitate the addition of observability in software systems' for projects where 'technical knowledge that may not be available' is load-bearing for the stated contribution but is supported only by the description of the blueprint and two author-led use cases; no usability evaluation, third-party deployment data, or metrics on required prior expertise are reported, leaving the 'facilitates' assertion as an untested assumption about transferability.

    Authors: We agree that the abstract's current wording implies broader transferability to teams without specialized expertise, which is supported only by the blueprint description and the two author-implemented use cases. The manuscript does not include usability evaluations, third-party deployment data, or metrics on required prior knowledge. To address this, we will revise the abstract to qualify the claim, stating that the toolkit 'provides guidance and deployable components to support the addition of observability' with emphasis on sustainability metrics, and note that its utility for reducing expertise barriers is illustrated in the use cases but requires further validation. This revision will be made in the next version of the manuscript. revision: yes

Circularity Check

0 steps flagged

No circularity: constructive architectural proposal with no derivation chain

full rationale

The paper presents a design proposal—an architectural blueprint plus deployment code—for adding sustainability observability (with energy measurement as a special case). It supports the proposal by describing the blueprint structure and illustrating it via two author-led use-case exemplars. No equations, fitted parameters, predictions, or first-principles derivations appear; the contribution is constructive rather than deductive. No self-citation load-bearing steps, uniqueness theorems, or ansatzes are invoked to justify core claims. The central assertion that the blueprint 'facilitates' observability for teams lacking expertise is an untested design claim, but it does not reduce to a self-referential definition or fitted input by construction. This is the normal case of a non-circular engineering proposal.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The central claim rests on the introduction of the blueprint itself, which draws on standard assumptions about software architecture and the benefits of observability without introducing new fitted parameters or external entities.

axioms (1)
  • domain assumption Software systems can be augmented with observable components for sustainability metrics
    Invoked implicitly when proposing the blueprint as a general solution.
invented entities (1)
  • Architectural blueprint for sustainability observability no independent evidence
    purpose: To define necessary components and deployment structure for adding observability including energy measurement
    Newly proposed in this work as the core contribution.

pith-pipeline@v0.9.0 · 5439 in / 1115 out tokens · 72583 ms · 2026-05-10T17:35:01.634018+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

23 extracted references · 23 canonical work pages

  1. [1]

    Newman,Building microservices: designing fine-grained systems

    S. Newman,Building microservices: designing fine-grained systems. O’Reilly Media, 2021

    work page 2021

  2. [2]

    A low-cost platform for environmental smart farming monitoring system based on IoT and UA Vs,

    F. A. Almalki, B. O. Soufiene, S. H. Alsamhi, and H. Sakli, “A low-cost platform for environmental smart farming monitoring system based on IoT and UA Vs,”Sustainability, vol. 13, no. 11, p. 5908, 2021

    work page 2021

  3. [3]

    A dashboard for microservice monitoring and management,

    B. Mayer and R. Weinreich, “A dashboard for microservice monitoring and management,” in2017 IEEE International Conference on Software Architecture Workshops (ICSAW). IEEE, 2017, pp. 66–69

    work page 2017

  4. [4]

    (2025) Boilerplate for the Architectural Blueprint

    Software and Sustainability Group. (2025) Boilerplate for the Architectural Blueprint. [Online]. Available: https://github.com/ andrei-calin-dragomir/software-monitoring

    work page 2025

  5. [5]

    Sustainable agriculture by the internet of things – a practitioner’s approach to monitor sustainability progress,

    S. Wolfert and G. Isakhanyan, “Sustainable agriculture by the internet of things – a practitioner’s approach to monitor sustainability progress,” Computers and Electronics in Agriculture, vol. 200, 2022

    work page 2022

  6. [6]

    Dairy victory platform: A novel bench- marking platform to empower economic decisions on dairy farms,

    E. Freitas and V . Cabrera, “Dairy victory platform: A novel bench- marking platform to empower economic decisions on dairy farms,”JDS Communications, vol. 6, no. 1, 2025

    work page 2025

  7. [7]

    The Dashboard of Sustainability to measure the local urban sustainable development: The case study of Padua Municipality,

    A. Scipioni, A. Mazzi, M. Mason, and A. Manzardo, “The Dashboard of Sustainability to measure the local urban sustainable development: The case study of Padua Municipality,”Ecological Indicators, vol. 9, no. 2, 2009

    work page 2009

  8. [8]

    Dashboards for input-evaluation of policy pro- grams: Lessons learned from an antwerp dashboard for garden streets,

    J. Vannieuwenhuyze, “Dashboards for input-evaluation of policy pro- grams: Lessons learned from an antwerp dashboard for garden streets,” ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. VI-4/W2-2020, 2020

    work page 2020

  9. [9]

    Tarara, D

    A. Tarara, D. Mateas, and G.-D. Hoffmann. (2026) Green Metrics Tool. [Online]. Available: https://github.com/green-coding-solutions/ green-metrics-tool

    work page 2026

  10. [10]

    (2024) Green Frame

    Green Frame project contributors. (2024) Green Frame. [Online]. Available: https://github.com/marmelab/greenframe-cli

    work page 2024

  11. [11]

    (2024) Cloud Carbon Foot- print

    Cloud Carbon Footprint project contributors. (2024) Cloud Carbon Foot- print. [Online]. Available: https://github.com/cloud-carbon-footprint/ cloud-carbon-footprint

    work page 2024

  12. [12]

    CEEMS: A resource manager agnostic energy and emis- sions monitoring stack,

    M. Paipuri, “CEEMS: A resource manager agnostic energy and emis- sions monitoring stack,” inSC24-W: Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis, 2024, pp. 1862–1866

    work page 2024

  13. [13]

    Exploration views: Understanding dash- board creation and customization for visualization novices,

    M. Elias and A. Bezerianos, “Exploration views: Understanding dash- board creation and customization for visualization novices,” inHuman- Computer Interaction – INTERACT 2011. Springer Berlin Heidelberg, 2011, pp. 274–291

    work page 2011

  14. [14]

    Snap4city dashboard manager: A tool for creating and distributing complex and interactive dashboards with no or low coding,

    P. Bellini, M. Fanfani, P. Nesi, and G. Pantaleo, “Snap4city dashboard manager: A tool for creating and distributing complex and interactive dashboards with no or low coding,”SoftwareX, vol. 26, p. 101729, 2024

    work page 2024

  15. [15]

    ExcelToShiny: An R Package for Automating Shiny Dashboard Creation from Excel Templates,

    L. Clements, “ExcelToShiny: An R Package for Automating Shiny Dashboard Creation from Excel Templates,”Journal of Open Source Software, vol. 10, no. 111, p. 7876, 2025

    work page 2025

  16. [16]

    Investigating performance overhead of distributed tracing in microservices and serverless systems,

    A. N ˜ou, S. Talluri, A. Iosup, and D. Bonetta, “Investigating performance overhead of distributed tracing in microservices and serverless systems,” inCompanion of the 16th ACM/SPEC International Conference on Performance Engineering, 2025, pp. 162–166

    work page 2025

  17. [17]

    V AMP: Visual analytics for microservices performance,

    L. Traini, J. Leone, G. Stilo, and A. Di Marco, “V AMP: Visual analytics for microservices performance,” inProceedings of the 39th ACM/SIGAPP Symposium on Applied Computing, 2024, pp. 1209–1218

    work page 2024

  18. [18]

    An empirical study of sensitive information in logs,

    R. Aghili, H. Li, and F. Khomh, “An empirical study of sensitive information in logs,” 2024. [Online]. Available: https://arxiv.org/abs/ 2409.11313v1

    work page arXiv 2024

  19. [19]

    Tracerank: Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems,

    G. Yu, Z. Huang, and P. Chen, “Tracerank: Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems,” Journal of Software: Evolution and Process, vol. 35, no. 10, p. e2413, 2023

    work page 2023

  20. [20]

    (2024) Feed4Food - Promoting Sustainable, Inclusive and Healthy City Food Systems

    Feed4Food project. (2024) Feed4Food - Promoting Sustainable, Inclusive and Healthy City Food Systems. [Online]. Available: https://feed4food.eu/

    work page 2024

  21. [21]

    Tocz ´e and K

    K. Tocz ´e and K. Vilkelis. (2025) Feed4Food. [Online]. Available: https://github.com/Ilydocus/feed4food

    work page 2025

  22. [22]

    Ten years of teaching empirical software engineering in the context of energy-efficient software,

    I. Malavolta, V . Stoico, and P. Lago, “Ten years of teaching empirical software engineering in the context of energy-efficient software,” in Handbook on Teaching Empirical Software Engineering. Springer, 2024, pp. 209–253

    work page 2024

  23. [23]

    Dragomir

    A. Dragomir. (2025) PeekStack. [Online]. Available: https://github.com/ andrei-calin-dragomir/PeekStack

    work page 2025