Separation of Concerns

The separation of concern refers to the division of tasks within a broader function or responsibility to separate different functions. The process is often used in management and business, where it allows for specialization of functions according to their area of expertise.

In software engineering, software modules whose functionality have been separated into concerns should be design-time interchangeable. A module that is designed with concerns in mind is also said to be modularised. The idea of separation of concern is particularly relevant in object-oriented programming, where the concerns are often the same class.

The same can be said for complex enterprise applications building blocks. Separating the various concerns into different systems or layers simplifies code navigation and maintenance. When changes are implemented, the effects and regressions on other areas are minimised, and a healthier and more adaptable programme emerges.

Let’s visit how the same philosophy can be applied in business.

Decentralisation of control

In business, decentralisation of control refers to the distribution of decision-making power away from one central authority. Decentralisation can have positive and negative effects. It can be used to foster creativity and innovation, but it can also lead to infighting, inefficiency, slow decision-making, inconsistent policies, and poor-quality decisions.

In the context of software engineering, decentralization of control can be applied in two ways:

1. In a module-based architecture, a module specifies a set of concerns and the way they interact. If a module provides a good abstraction and has its internal implementation sufficiently separate from the next module, then it can be exchanged for another module, and the internal implementation can be changed wholesale without affecting any external behaviours.
2. In a layered architecture, the lower level layers implement the bare minimum to support all the higher-level layers. Ideally, the lower level does not need to be concerned about higher-level functionality. It can be designed independently of them and independently evolve over time.

Decoupling

Decoupling is the ability of two parts that are connected or related to function independently from each other. A good example of decoupling is putting a car engine in a boat to make it faster. Decoupling can be used without damaging the system itself.

In OOP, decoupling is often considered cohesiveness. High cohesion occurs when the elements of a module are well related to each other. Low cohesion means that the elements are not closely related to each other.

The philosophy behind this concept for the business is that by keeping functional areas, such as accounting and management, separate and independent from each other, the enterprise can function more efficiently. The same principle applies to software development for modularity and reusability.

This disconnection is intended to prevent repetition and redundancy. So that the segment or section can perform the best. It same philosophy behind microservice architecture. By avoiding functions duplication, any errors found will only need to be fixed once. Changes to one area of code will not have unintended effects on other areas of the programme.

One way separation of concerns or decentralization of control be implemented is by having a different leader for different areas, and having one leader who overlaps the other leaders.

How the SOC benefits the design business

The separation of concerns helps to keep the department clean, accessible and highly reusable. The modularity in business is designed into different areas so that it can be easily modified and changed to cope with business changes. Modular operation is structured, well structured and easily navigate. There is a positive effect in communication and coordination between different business departments through this strategy.

The benefit of modularity is the separation of concerns, which involves different concepts such as abstraction, coupling and cohesion. We can view the department as like code and classes in a program. Divide and conquer, decentralization or whatever we may call it, has a positive impact on conducting an independent operation.

Like software engineering, it helps with the reuse of different parts without having to write tedious procedures for each part, save time and effort when it comes to diagnostic. It also provides a simple method for building blocks, allowing the system to be re-used in different projects with minimal effort. The separation of concerns also aids in continuous integration and feedback, both of which are critical when developing the business.