Single-responsibility principle says:
Every class in a computer program should have responsibility over a single part of that program's functionality, which it should encapsulate. All of that module, class or function's services should be narrowly aligned with that responsibility.
Therefore,
"A class should have only one reason to change".
I have seen this principle being applied to multiple concepts like modules, APIs, Systems, etc. But I haven't seen it applied to an Organization yet. Maybe because it doesn't make any sense at all, but I will try to resonate about it.
Bear with me, we might not get into any point but worth to try it out 😁
Let's start replacing computer concepts by organization concepts
Every
classorganization in acomputer programsociety should have responsibility over a single part of thatprogram;s functionalitysociety's needs, which it should encapsulate. All of thatmodule, class or function's servicesorganization, product or entity should be narrowly aligned with that responsibility.Therefore,
"An organization should have only one reason to change".
Does it have any sense at all? It depends.
Single-responsibility seems to only make sense at Why level (company's purpose), not at What level (what the company offers, like products and services).
When I say why level and what level, I'm referring to the Golden Circle by Simon Sinek in his book, Start with Why.
So, in order to be a SOLID Organization, you need...
to have a single and well defined organization's purpose, which it should drive why the organization exists in the first place.
The only reason to an organization to change is that the purpose isn't useful anymore.
It might be that:
- The purpose is already accomplished
- There is no need to exist because there is not a demand
- People don't believe in the purpose anymore
Discussion and feedback welcomed 😁
What do you think? Are you in a SOLID Organization? Does this make any sense? 🤣
Top comments (2)
I think it certainly does make sense. Would it also be possible to go one level deeper and apply SOLID to teams within an organisation?
Thank you for sharing your explorations! I look forward to the next part in the series :)
I agree. I think that SRP is not only a software design principle, but a system design principle. I think any kind of complex system can benefit from this principle!
Organizations, departments and teams are complex systems, just like software.
The departments that make up an organization can have responsibilities within that organization, to help the organization achieve its goals. The teams within a department have responsibilities to help the organization achieve its goals. And the individual roles within a team also have their own responsibilities to contribute towards the teams success. (I say role and not person, because multiple people can have the same role in a team).
Using single responsibility principle, keeps teams focussed, stops them from getting overloaded, and stops other teams doing duplicate work.
In practice, it might not be practical to adhere to just one responsibility, but over time as an organization grows and changes, the principle can be used to "refactor" your organization and team structures. For example, if one job role is having to do lots and lots of different things, maybe you need to split the role up and hire somebody else to take responsibility for some of the work.