Interaction-Oriented Software Engineering: Concepts and Principles

Following established tradition, software engineering today is rooted in a conceptually centralized way of thinking. The primary SE artifact is a specification of a machine – a computational artifact – that would meet the (elicited and) stated requirements. Therein lies a fundamental mismatch with (open) sociotechnical systems, which involve multiple autonomous social participants or principals who interact with each other to further their individual goals. No central machine governs the behaviors of the various principals. We introduce Interaction-Oriented Software Engineering (IOSE) as an approach expressly suited to the needs of open sociotechnical systems. In IOSE, specifying a system amounts to specifying the interactions among the principals as protocols. IOSE reinterprets the classical software engineering principles of modularity, abstraction, separation of concerns, and encapsulation in a manner that accords with the realities of sociotechnical systems. To highlight the novelty of IOSE, we show where well-known SE methodologies, especially those that explicitly aim to address either sociotechnical systems or the modeling of interactions among autonomous principals, fail to satisfy the IOSE principles.

💡 Research Summary

The paper opens by observing that contemporary software engineering (SE) is fundamentally rooted in a centralized worldview: the primary artifact is a specification of a single “machine” that, when built, satisfies a set of elicited requirements. This paradigm works well when a system has clear boundaries and a single controlling entity, but it collides with the nature of open sociotechnical systems. In such systems multiple autonomous principals—people, organizations, services—interact to achieve their own goals, and no central machine dictates their behavior. The authors argue that this mismatch creates a conceptual gap that hampers the design, analysis, and evolution of real‑world, distributed socio‑technical environments.

To bridge the gap they propose Interaction‑Oriented Software Engineering (IOSE). Rather than describing a monolithic computational artifact, IOSE treats the specification of a system as the definition of the interactions among principals, expressed as formal protocols. A protocol enumerates the permissible messages, the obligations and rights that each message creates, and the roles that participants assume. In this view, the system is not a piece of software that runs in isolation; it is a set of mutually agreed‑upon interaction rules that enable autonomous actors to coordinate while preserving their independence.

The paper re‑examines the four classic SE principles—modularity, abstraction, separation of concerns, and encapsulation—and re‑interprets each in the context of interaction‑oriented design:

1. Modularity becomes role‑based. Instead of decomposing a program into functions or classes, IOSE decomposes a sociotechnical environment into roles (e.g., buyer, seller, regulator). Each role owns a slice of the protocol and can be implemented independently.

2. Abstraction shifts from data‑structure or algorithmic detail to social meaning. The essential abstraction is the semantics of a message (e.g., “contract formation”, “payment authorization”) rather than the concrete payload format.

3. Separation of concerns distinguishes system design (the shape of the protocol) from policy design (the concrete actions each role may take within the protocol). Designers can evolve policies without altering the underlying interaction skeleton.

4. Encapsulation no longer hides internal state from other components; it hides the internal decision logic of a role while exposing only its declared obligations and rights. Other participants interact solely through the protocol’s interface.

To illustrate the novelty of IOSE, the authors compare it with several well‑known SE approaches that attempt to address sociotechnical concerns (e.g., Socio‑Technical Systems Engineering, Actor‑Network Theory‑inspired methods) and with interaction‑focused modeling techniques (e.g., Interaction‑Oriented Modeling, choreography languages). They show that these alternatives either still assume a central machine, treat interactions as secondary after the functional decomposition, or lack a principled reinterpretation of the classic SE concepts. Consequently, they fail to satisfy the IOSE principles fully.

Two detailed case studies ground the discussion. In an e‑commerce scenario, the participants include buyers, sellers, payment gateways, and logistics providers. The IOSE protocol specifies a sequence of messages such as “order request”, “payment authorization”, “shipment notice”, and “delivery confirmation”, each creating specific obligations (e.g., the seller must ship after payment is authorized). By modeling the system as a protocol, each participant can be implemented independently, swapped out, or upgraded without breaking the overall coordination.

In a health‑care collaboration scenario, the actors are patients, physicians, insurers, and pharmacies. Traditional electronic health‑record systems impose a central repository that controls data flow. The IOSE approach replaces this with a “care‑coordination protocol” that defines who may request, approve, or dispense medication, and under what conditions. The protocol captures privacy constraints and liability obligations directly in the interaction rules, allowing each organization to retain control over its own data while still participating in a coherent care process.

The authors acknowledge several open challenges. First, formal verification of protocols remains nascent; while the paper sketches a logical foundation, scalable tool support is lacking. Second, dynamic agreement—how new principals join or existing ones change roles at runtime—requires mechanisms for safe protocol evolution. Third, integration with legacy centralized systems is non‑trivial; bridging the gap may demand adapters that translate protocol messages into traditional API calls.

In conclusion, IOSE offers a paradigm shift: it reframes software engineering from “building a machine” to “designing a set of interaction contracts”. This shift aligns the discipline with the realities of open, multi‑principal environments, providing clearer responsibility attribution, better modularity, and greater flexibility. Future research directions include developing automated verification techniques, runtime governance models for protocol evolution, and hybrid methodologies that combine the strengths of centralized and interaction‑oriented approaches. The paper positions IOSE as a foundational step toward a more socially aware, interaction‑centric engineering discipline.