What Is Separation of Concerns?

Edsger W. Dijkstra coined the term in 1974, in his essay “On the role of scientific thought” (EWD447), published in the E.W. Dijkstra Archive at the University of Texas at Austin. In it, he describes it as the only effective way to deal with the complexity of a problem: focusing on a single aspect at any given moment, without losing sight of the other aspects and how they interact.

A concern is a well-defined responsibility of a system — capturing measurements, storing them, securing them, or displaying them, for instance. Separation of concerns requires that each part of a system carry exactly one such concern and know the other parts only through a defined interface.

The idea was formalized shortly afterward in structured analysis and structured design: W. P. Stevens, G. J. Myers, and L. L. Constantine described the concepts of coupling and cohesion in 1974 in the IBM Systems Journal as measurable indicators of good separation.

Without separation, every part of a system can, in the worst case, know every other part: with six modules, that is up to fifteen possible dependencies, with ten, up to forty-five — the same arithmetic that describes coupling between individual IT systems. Every change to one module can then touch every other one, and no one can predict alone what a small adjustment will actually affect.

Separation of concerns reduces these dependencies to defined interfaces between a small number of parts. A data-capture module can change without the analysis layer noticing, as long as the interface between them stays the same. The separation does not make a system smaller, but it makes it understandable — and, more importantly, changeable, without every change turning into an investigation of the whole system.

These two measures from structured analysis can be read off any system — whether it consists of code, of equipment, or of organizational units.

The goal is not to eliminate coupling entirely — no system works without connections between its parts — but to concentrate it into a small number of named interfaces instead of letting it spread uncontrolled across the whole system.

• IT/OT separation. Responsibility for production control (OT) is separated from responsibility for office IT — not out of distrust, but because the two follow different requirements for availability, update cadence, and failover.
• Zones and conduits under IEC 62443. The standard divides an automation network into security zones with comparable protection needs and allows communication between them only through defined, monitored crossings (conduits) — separation of concerns as a security architecture.
• Unified Namespace. A namespace separates the responsibility for holding data (the current state of each source) from the responsibility of each individual application that uses that data — source and consumer never know each other, only the name of the information.
• Layered architecture. The classic split into data capture, data storage, business logic, and presentation is the oldest and most widespread application of the principle.

• Interfaces as a contract. An interface (API) defines what one part may expect from another — and what it may not. If the inside of a module changes without touching the interface, the rest of the system never notices.
• No shared data access across responsibilities. Each module owns its data; other modules query it instead of reading or writing directly into a shared database — otherwise coupling forms that no interface makes visible.
• Event-driven decoupling. A publish-subscribe pattern, the same one underlying a Unified Namespace, decouples source and consumer in both time and technology: both only know the name of the information, not each other.
• Versioning. Interfaces do change eventually — a version number makes visible which side is speaking with which expectation, instead of breaking silently.

1. Name the responsibilities

   What concerns actually exist — data capture, security, analysis, presentation? The list comes from the task at hand, not from the technology already in place.

2. Define interfaces instead of direct access

   Every responsibility gets an interface other parts use to address it — never direct access to its internal data.

3. Assign ownership

   A responsibility should be clearly owned by one team or role — otherwise the technical separation does not hold either.

4. Check the separation

   The bulkhead test: does a change in one part regularly force changes in another part that should have nothing to do with it? If so, the boundary is drawn in the wrong place.

• Not an argument for any number of layers. The number of parts follows the number of genuinely distinct responsibilities — not a layer count someone believes is correct.
• Not a substitute for defining an interface. Putting two modules into separate files or services without specifying what they may expect from each other separates nothing — it only renames the problem.
• Not a purely technical matter. How a system is broken apart is closely tied to how the teams building and running it are organized — an observation known in software development as Conway’s Law.
• Not an end in itself. A separation no one uses for changes, testing, or ownership is just extra effort with nothing to show for it.

• Over-separation. For a small, stable system, six neatly separated layers can cost more in interface upkeep than they gain in clarity.
• Wrong boundaries. Separating along technical lines (say, by database table) instead of along actual responsibility means a single business process still ends up touching several modules at once.
• The distributed monolith. Modules are deployed as separate services but still hit the same database and call each other synchronously everywhere — the result combines the complexity of a monolith with that of a distributed system, without the benefits of either.
• Missing ownership. A responsibility with no clear owner drifts back into being mixed with others over time, even if the technical separation was clean to begin with.

pronubes is the platform between the shop floor and IT — built on the same principle it delivers to its customers.

• pronubes Edge carries exactly one responsibility: capturing raw data at the source and buffering it through connection loss.
• pronubes Zones carries the responsibility for structure and naming — independent of which application later uses the data.
• pronubes Insights carries the responsibility for analysis and visibility, without capturing or structuring data itself.

Each component talks through a defined interface rather than a shared database — so replacing one piece never turns into rebuilding the whole landscape. More on the platform