An Empirical Study on the Effects of Jayvee, a Domain‐Specific Language for Data Engineering, on Understanding Data Pipeline Architectures - Heltweg, Philip; Schwarz, Georg-Daniel; Riehle, Dirk; Quast, Felix (Software-Practice & Experience, 2025)
A large part of data science projects is spent on data engineering. Especially in open data contexts, data quality issues are prevalent and are often tackled by non-professional programmers. We introduce and evaluate Jayvee, a domain-specific language for data engineering aimed at reducing barriers to building data pipelines. We show that a structured DSL can have positive effects on speed, ease of use, and quality for data engineering by non-professional developers. For this, we present an empirical quantitative study, in which we compare the performance of students as proxies for non-professional programmers using Jayvee with Python and Pandas. We search for reasons for the empirical findings using a follow-up interview study on how using a DSL changes how non-professional programmers build data pipelines. Participants solve a subset of tasks faster, more easily, and with higher quality when using Jayvee compared to Python. Interviewees describe tradeoffs regarding the DSL's more limited features, stricter code structure, and explicit descriptions. Jayvee is found to be more approachable, which leads to a more guided development flow. New data engineering languages should provide good tooling and documentation, plan how to visualize intermediate data and consider new development workflows involving tools like ChatGPT to find adoptio
Keywords: data engineering; domain-specific language; empirical study; evaluation; open data; programming language

A taxonomy of microservice integration techniques - Schwarz, Georg-Daniel; Bauer, Andreas; Riehle, Dirk; Harutyunyan, Nikolay (Information and Software Technology, 2025)
Context: Microservices have become an important architectural style for building robust and scalable software systems. A system’s functionality is split into independent units, the microservices, that communicate over a network and can be deployed independently. The shift of complexity into the integration layer necessitates enhanced collaboration among stakeholders, stressing the importance of effective communication. Objective: We aim to streamline communication between stakeholders in microservice-based projects by constructing a framework for enhanced clarity, a taxonomy, by answering our research question: “How can microservice integration techniques be classified?” Method: We conducted a thematic analysis of literature and six expert interviews to identify microservice integration techniques and construct a taxonomy. Results: The results of this study are (i) a taxonomy for microservice integration techniques consisting of five main and ten refined categories, (ii) the classification of 121 found integration techniques, (iii) an illustration of the taxonomy usage based on three selected techniques to demonstrate the procedure in case of classification ambiguity, (iv) a comparison of data gathered from literature with the interviews, and (v) comprehensive supplementary materials. Conclusion: The taxonomy offers a structured framework to classify microservice integration techniques and enhances the understanding of the diverse landscape of microservice integration techniques, including organizational ones that are often overlooked. Practitioners can discover integration techniques through the taxonomy and apply them with guidance provided in the supplementary materials.
Keywords: Microservices; Integration; Techniques; Taxonomy

Challenges of Tracking and Documenting Open Source Dependencies in Products: A Case Study - Bauer, Andreas; Harutyunyan, Nikolay; Riehle, Dirk; Schwarz, Georg-Daniel (Proceedings of the 16th International Conference on Open Source Systems 2020 (OSS 2020), 2020)
Software vendors need to manage the dependencies of the open source components used in their products. Without this management, license compliance would be impossible, export restrictions could not be maintained, and security vulnerabilities would remain unknown to the vendor. The management of these dependencies has grown in an ad-hoc fashion in most companies. As such, vendors find it hard to learn from each other and improve practices. To address this problem, we performed exploratory single-case study research at one large established software vendor. We gathered and analyzed the key challenges of tracking and documenting open source de- pendencies in products. We wanted to understand whether these ad-hoc solutions could be based on a single unified conceptual model for managing dependencies. Our study suggests that underlying the various point solutions that we found at this vendor lies a conceptual model that we tentatively call the product (architecture) model. In future cross-vendor work, we will investigate whether this conceptual model can be expanded to become a unifying model for all open source dependency management. <br
Keywords: Open source software; FLOSS; FOSS Open source governance

What Microservices Can Learn From Enterprise Information Integration - Schwarz, Georg-Daniel; Riehle, Dirk (HICSS-53, 2020)
Microservices are an architectural style in which each service typically provides the complete stack of functions from a user or application programming interface through a domain model all the way to storage for that model. As a consequence, querying conjunct data from different microservices becomes a non-trivial engineering task. In this article, we review older and established general data integration theory in the enterprise context and then compare current microservice practice with enterprise information integration (EII) theory as an established approach to data integration. We find that microservices do not utilize all possible approaches for data integration that are common in enterprises. Specifically, microservices use middleware only partially and databases are not used at all to integrate data. Therefore, we further investigate whether, when, and how these two approaches can be used in a microservices context and present our findings. With our findings, we (i) clear the way for fellow researchers to investigate and improve unused integration strategies with microservices and (ii) raise the awareness of practitioners that some integration strategies may not work out of the box with microservices as they do in EII.<br
Keywords: microservices; integration; EII