Farmers face an increasing administrative burden as agricultural policies and certification systems of trade partners ask for more sustainability reporting. Several indicator frameworks have been developed to measure sustainability, but they often lack empirical operationalization and are not always measured at the farm level. The research gap we address in this paper is the empirical link between the data needs for sustainability reporting and the developments in data management at the farm level. Family farms do not collect much data for internal management, but external demand for sustainability data can partly be fulfilled by reorganizing data management in the farm office. The Farm Financial Accounts (FFAs) and Farm Management Information Systems (FMISs) are the main data sources in the farm office. They originate from the same source of note-taking by farmers but became separated when formalized and computerized. Nearly all European farms have a bank account and must keep financial accounts (e.g., for Value-Added Tax or income tax) that can be audited. Financial accounts are not designed for environmental accounting or calculating sustainability metrics but provide a wealth of information to make assessments on these subjects. FMISs are much less frequently used but collect more technical and fine-grained data at crop or enterprise level for different fields. FMISs are also strong in integrating sensor and satellite data. Integrating data availability and workflows of FFAs and FMISs makes sustainability reporting less cumbersome regarding data entry and adds valuable data to environmental accounts. This paper applies a design science approach to design an artifact, a dashboard for sustainability reporting based on the integration of information flows from farm financial accounting systems and farm management information systems. The design developed in this paper illustrates that if invoices were digitized, most data-gathering needed for external sustainability reporting would automatically be done when the invoices is paid by a bank transfer. Data on the use of inputs and production could be added with procedures as in current FMISs, but with less data entry, fewer risks of differences in outcomes, and possibilities of cross-checking the results.

Service-centric systems exist in a very dynamic environment, which requires these systems to adapt at runtime in order to keep fulfilling its QoS requirements to its users. In order to create self-adaptive service-centric systems, developers not only design the service architecture, but need to design the self-adaptability aspects in a structured way. Current service standards and technologies do not provide a general architecture in which all aspects for self-adaptability can be designed. In this paper we propose DySOA (dynamic service-oriented architecture), an architecture that extends service-centric applications to make them self-adaptive. DySOA allows developers to explicitly model the process and components that deal with determining the QoS of the running system, with evaluating the QoS, and with reconfiguring the system when necessary. Having the DySOA elements explicit enables separation of concerns, making the DySOA elements adaptable at runtime and reusable in next versions. We demonstrate how to use DySOA with an example.