Software Bureaucracy: Layering Optimizes Downward, Not Upward Collaboration
10/11/2009 2:38:00 PM
The Layering architecture style is one way to structure an application and separate concerns into a hierarchy of layers. The question is then: are layers efficient? aren't we adding more obstacles and making things more complex? What gives?
It All Started With Delegation
Layering is just organized delegation. Delegation is good. Before Layering, there was delegation. To enable a component to do more, it delegated the task to another component to be executed. That's one layer created already. Everything was fine with one layer (flat structure) until the tasks in that first layer became more in number or more complex and it became more efficient to delegate to yet another layer.
It is also important to note that a delegatee should be usable by any delegator. It should not be bound to one delegator. This promotes reusability, scalability and maintainability.
As you can see, each layer is created out of a need to optimize for the layer on top. There's nothing wrong with that. If we don't layer, and go with a flat structure instead, the top layer will have to communicate with all, decreasing its efficiency and defocusing it from its main responsibility, as a result, leading to ineffectiveness. Total failure.
Lower Layers Should Not Call Upward Ones (Software Bureaucracy)
Just like a delegatee should not be bound to one delegator, a layer should not know or be bound to one specific layer above it, or depend on the layers above to do its job.
As you have observed above, the whole strategy behind the layering architecture style it so focus the top layers on their main responsibility to achieve more and better results. The key to remember here is that layering was not fabricated to help the bottom layers.
What happens when the lower layers initiate the communication going upwards to each layer? Inefficiency, decreased performance and low maintainability. Because now, lower layers have to keep track and know each top layer in order to initiate communication with them and to do their job. This adds cyclic dependencies and chaos in general. Usually, these kind of software applications are not extensible and provide a very low return on investment.
When this mis-application of layering is done in the business world in corporate hierarchies, it is called bureaucracy, and that's not a good thing. I chose the term Software Bureaucracy as a term for this condition.
Because of this misunderstanding of the layering architecture some people dismiss the whole style altogether.
Then How to Communicate Upwards?
Communicating upwards is best done without dependency. Dependency on upper layers is at the core of the problem. The best way to implement that is through the publish-subscribe pattern or the Observer pattern. If any component is interested in the lower layers' work, then just subscribe to their events. This achieves the best of both worlds. Top layers are now in-the-know and lower layers do not have to depend on communication with the top layers. They just fire and forget. No obstacles in their way.
This architecture can be extended to the business world to benefit from. Keep the corporate hierarchy optimized but empower the lower levels and employees to make their own decisions without the need to depend on top managers. To keep top managers informed, employees can update one central corporate system about their current issues and status.
Who said that business cannot benefit for software architecture :)
