Doc SoC
Doc SoC Researcher (software architecture and service-oriented computing).

EuroPLoP 2026: AI Impact on Software Architects, IoT Service Granularity Patterns


Reading time: 4 minutes
EuroPLoP 2026: AI Impact on Software Architects, IoT Service Granularity Patterns

I co-organized a focus group at EuroPLoP earlier this year and also contributed to a paper mining service design patterns in the context of monitoring sensors and controlling actuators. This post summarizes the key messages of the focus group report and the fresh patterns.

To give you some context information: EuroPLoP is the European conference on patterns and pattern languages for “knowledge sharing in the fields of software development, system design, human computer interaction, education, business and many more”. Our Patterns for API Design and the follow-on Interface Refactoring Catalog went through EuroPLoP writers’ workshops from 2017 to 2025.1

Focus Group “What Will Remain Human in Software Architecture?”

The focus group lasted 90 minutes and had 22 participants. As a moderated plenary discussion, it was structured in six parts:

  1. Current use of AI tools for architecture tasks
  2. Trust and validation of AI proposals
  3. Tasks that remain fundamentally human
  4. New responsibilities and governance
  5. Autonomous decisions and accountability
  6. Implications for education and skill development

The discussion reconfirmed many messages currently sent in blogs and conferences, but also yielded some fresh insights. We found criticality, the combination of uncertainty and cost of change, to be well-suited to calibrate decisions about AI and agent autonomy: low criticality permits more autonomy and less human verification; high criticality demands human control and full understanding.

Outsourcing was mentioned several times as a metaphor for human-AI collaboration, and cognitive debt was seen as a big risk. If agents code and deploy autonomously, how can humans keep track of and understand what is going on? Can accountability be outsourced?

Harness engineering was a major topic unsurprisingly. It addresses the shift of engineering effort from application code to the governance layer and the encoding of company knowledge into reusable guardrails:

“Harness engineering is the design, implementation, and maintenance of the socio-technical system that governs AI-assisted software creation.”

“Harness engineering for coding agent users” provides an introduction.

The focus group discussion also revealed several tensions (i.e., conflicting forces):

  • Efficiency vs. skill preservation
  • Acceptance without full understanding vs. insistence on deep comprehension
  • Maintainability in an era of regeneration
  • Individual brilliance vs. adequate solutions

Our focus group report describes the discussion themes and the tensions in the list in detail. A preprint (PDF) is available.

My co-organizer and report co-author Uwe van Heesch summarizes his impressions on LinkedIn as this:

“these results pushed me to think harder about intellectual sovereignty in software engineering. The question is no longer only how AI builds high-quality, maintainable software, but how we keep intellectual ownership of our systems while still capturing the efficiency gains.”

He concludes:

“this is also what should set us software engineers apart from non-professional vibe coders: we take the efficiency gains, but we hold on to the standards of our discipline and make sure we can still understand and account for what we build.”

I could not agree more and took this mental model away:

EP26: AI Focus Group Retrospective

Writer’s Workshop D: Montauciel

EuroPLoP focuses on improving papers via shepherding and writers’ workshops. Shepherding2 happened before the conference (for about 3 months); the writers’ workshops3 form the heart of the conference.

Ronny Seiger, Daniel Lübke and I had the paper “Granularity Patterns for Programming Cyber-physical Systems with Business Processes” workshopped. The paper and its patterns investigate the following two questions:

  • At what granularity level do we represent and integrate sensing in executable business processes?
  • At what granularity level do we represent actuation in executable business processes, and what is left to their code-based implementation?

To help answer these questions, we introduce a sample process from the Internet-of-Things (IoT) and Cyber-Physical Systems (CPS) domain:

EP26: Sample Scenario (BPMN)

We discuss the following forces for this and similar scenarios:4

  1. Process model complexity refers to the number of elements in the process model, their names and interrelations.
  2. Process understandability refer to how easy the logic of sensing and actuation in a process model can be understood by humans.
  3. Reusability refers to the ease of using existing modeling elements for sensing and actuation in other process models.
  4. Process observability refers to the degree of detail that the execution of sensing and actuation can be monitored at the process level.
  5. Ownership of code and APIs refers to the degree of which access and modification to the CPS control code implementing the actual sensing and actuation is possible and how comprehensive the APIs of the CPS are.
  6. Communication overhead refers to the amount and frequency of information exchange between the business process management system and the CPS that is needed to execute the sensing and actuations modeled in a business process.
  7. Real-time and safety refers to requirements imposed by the CPS to realize and guarantee safety and real-time constraints during the execution of sensing and actuations.

The four patterns resolve these forces in different ways. They are:

  • Fine-grained Sensing in Processes
  • Coarse-grained Sensing via Transformation Services
  • Fine-grained Actuation in Processes
  • Coarse-grained Actuation via Controllers

Long but expressive names! In the paper, BPMN snippets serve as solution sketches explaining the design options. Coming back to the forces, we introduce decision force field analysis diagrams to show how the granularity patterns resolve them. Here’s the one for actuation:

EP26: Forces Resolution Actuation Patterns

The authors copy of our paper is available as a preprint (PDF).5

Join the Community

Did you get interested in participating in a pattern conference?

Consider a submission to EuroPLoP 2027. Submissions are due early next year, so there is time. Coaching and tools for beginners are available — check out the “Start Writing” section on this page on the EuroPLoP website. An introductory information pack is available for download.

– Olaf

Olaf’s and Ronny’s work has received funding from the Swiss National Science Foundation (TaSSAreCt project).

  1. Links to conference editions and other conferences can be found here. ↩

  2. Shepherding is pattern community lingo for coaching w.r.t. technical writing and patterns. ↩

  3. Authors read each other’s papers before the conference and then discuss them on-site, following a specific protocol. ↩

  4. Pattern community lingo again. Forces make the problem interesting and hard to solve; they often conflict with each other. ↩

  5. Many of the workshopped papers will eventually be published in the conference proceedings. Twp examples from previous EuroPLoPs are “Interface Responsibility Patterns: Processing Resources and Operation Responsibilities” and “API Refactoring and Reengineering: Distribution Patterns and Evolution Strategies”. ↩