“Write programs that do one thing and do it well,” said Douglas McIlroy, one of the key architects of Unix at Bell Labs. This philosophy has shaped software development for decades, influencing everything from API-driven microservices and containerization to WebAssembly, kernel design, and domain-specific language libraries. At its core, this principle embodies the separation of concerns (SoC) — the practice of designing software as modular components that serve distinct functions and operate independently.

SoC is a foundational concept in software engineering, closely aligned with principles like don’t repeat yourself (DRY), SOLID, and clean architecture. It’s often restated as the single responsibility principle (SRP) — the idea that each unit of software should have a well-defined purpose.

From separating the UI layer from the backend to composable APIs, SoC helps teams break down large projects into manageable, focused components. “Generally, when approaching a problem, it’s a good idea to split concerns early on,” says Jacob Ideskog, CTO of Curity. “It’s fundamental to how you structure any system.”

But as AI-driven development accelerates, is SoC still as relevant as it once was? Below, we examine its role in modern software and whether emerging trends are reshaping how we think about modularity and API-driven microservices.

What Is Separation of Concerns (SoC)?

Separation of concerns (SoC) is not a hard and fast standard — it’s more of an architectural philosophy that realizes itself in various ways. Sometimes, it makes sense to break things down further into individual building blocks or ‘concerns.’ In this context, a concern refers to a specific problem a software unit is designed to solve.

Manifestations of this principle are everywhere — from the Bash Terminal to microservices architectures, ephemeral containerized workloads, and beyond. “This design principle is all over the place,” says Ideskog. As such, SoC is timeless and always relevant. “It hurts the eye of a senior engineer when you mix concerns — it’s something that experience gives you.”

While certain monolithic architectures remain valid, modularity has become the dominant trend. Most modern products are actually an amalgamation of distinct units — Postman’s 2024 State of the API Report found that between 26 and 50 APIs power the average application.

The Benefits of SoC

Separating concerns creates extensible, adaptable software that is easier to maintain. “We did that early on when building an identity system for that same reason,” says Ideskog. “Breaking things apart makes it much easier to grow over time.”

Without SoC, tightly coupled components can make scalability a nightmare. For example, if frontend experiences are tightly coupled with backend logic, even minor updates could require duplicating and tweaking the same code across multiple places. Poor modularization also leads to relearning and reworking code over time, adding unnecessary friction.

By contrast, SoC reduces duplication, improves discoverability, and helps developers navigate a well-structured project more efficiently. If your software does a particular thing well and can interact with other components using standardized APIs, you’re better suited for the unknown, says Ideskog. Separating concerns — without over-engineering — creates future-proof software that can evolve alongside business needs.

Beyond code, this mindset applies to product development and system architecture. Take API security, for example — modern ecosystems rely on distinct external components like API management platforms, monitoring tools, and gateways. Each plays a unique role, yet they must all integrate seamlessly.

Example of SoC: Modern Identity Systems

A real-world example of SoC can be found in decoupled identity systems. Customer identity and access management (CIAM) involves multiple login standards, legacy data systems, and authentication flows that must work together well. “That’s hard to solve on a point-to-point or custom basis,” says Ideskog. “You have to think of that from an architectural perspective.”

Identity architectures rely on modular components with distinct responsibilities to handle diverse authentication preferences and user data storage needs. At Curity, identity is structured around four core building blocks:

• Authentication service: Standardizes authentication workflows for various clients, handling multiple login methods, including 2FA and MFA.
• Secure token service: Functions as an OAuth server, issuing and validating tokens for APIs and applications.
• Federation service: Operates at the application layer, enabling cross-domain access using standards like SAML and OpenID Connect.
• Profile service: Manages user account data and handles data at rest.

Although these building blocks form the foundation, they’re not the end of the story. Identity architectures often require further granular separation. “When we lay things out, we ask: ‘Do we create a new box, or does this fit into an existing one?'” says Ideskog. For instance, the rise of decentralized identity introduces new complexities — such as the need for a dedicated component to manage the issuance of verifiable credentials, he adds.

PushBack on SoC

Of course, putting everything in its neat and tidy box has some potential negative consequences. For example, sometimes, developers can take the theory too literally and overdo everything with cool granular design patterns, which could hinder productivity.

To counter this, some developers follow “The Rule of Three),” popularized by Martin Fowler in Refactoring. The rule suggests that code should only be refactored into reusable components if it appears three or more times, preventing premature abstraction.

The reusability benefits of SoC are also often overemphasized, says Ideskog. Sometimes, you simply never reuse a component. However, when reuse does become necessary, failing to separate concerns early on can make extracting functionality far more difficult later.

Many sound arguments can also be made against microservices architectures. The reality is microservices architectures often require additional networking overhead, observability tools and new deployment patterns to functionally maintain a web of services.

But even with monolithic development, SoC still often plays a role in defining clear boundaries. “Fundamentally, everything needs to be separate processes or separate machines,” says Ideskog. “It can be one program but separated.” Although a use-case-specific application, like a photo editor, could be considered monolithic, it’s still composed of separate modules.

While SoC remains a guiding principle, knowing when to separate concerns — and when to avoid unnecessary complexity — is an intuitive process that comes with experience.

Is SoC Fading in the AI Age?

The rise of AI-driven development introduces new challenges to traditional software design principles. While generative AI coding assistants can dramatically improve productivity, they often lack the ability to see the bigger picture, making refactoring more difficult and contributing to technical debt concerns.

Although decoupled architectures remain valuable, Ideskog notes that the industry has drifted somewhat away from the SoC mindset in the AI age. “AI doesn’t really provide solutions for this,” he says. “As with any new tech, you can’t see those boxes clearly at first — it becomes cloudy. However, as the tech matures, it crystalizes, and it gets back to that state.”

While some argue that SoC is going out of style in certain areas, it remains deeply embedded in others. Ideskog points to Kubernetes manifests, which explicitly define the roles of individual components. Similarly, the TCP/IP model, a foundational aspect of the internet, maintains a clear separation between the application, transport, and network layers.

SoC: Essential for Modern Development

Despite shifts in software trends, separation of concerns remains an essential aspect of modern development. It continues to serve as a cornerstone of scalable architecture, even if it isn’t always in the spotlight.

In short, modularity is ongoing. Countless enterprises are still in the process of splitting up their monolith. They simply can’t scale with this approach, says Ideskog — the costs are too high. While microservices and decoupled architectures are not the default for every use case, they remain key strategies in digital transformation efforts aimed at untangling tightly coupled systems.

That said, SoC isn’t always formally codified — sometimes, it’s just theoretical boxes on paper. Therefore, knowing when to separate concerns and understanding your decisions’ business impact and maintenance implications is largely an intuitive process — something senior engineers have a sixth sense for.

SoC can mean different things to different people. But, for most technical leaders, it’s pivotal to systems thinking at large. “As systems grow, if you don’t get organized, you’re going to hit the wall,” he says. “I see the separation of concerns as a pretty important cornerstone to avoid technical debt.”