While using object oriented design principles and patterns for architecture and design of software projects, I realized that some of these patterns and principles can be very effectively used for building an organization structure. The key object oriented design principles, also known as SOLID principles, are enlisted below:
I am working on an elaborate model to describe object oriented design principles and organization design. Some of the key principles that can be immediately applied for organization design are:
1. While building teams, user groups or functional units, every unit should assume responsibility over a single part of overall business activity which should be entirely encapsulated from other units. Two aspects of a problem are really two separate responsibilities, and should therefore be in a separate encapsulation unit of sub-teams, teams, departments, sub-systems, systems and/or business units depending on the level of abstraction considered during analysis.
2. With significantly volatile business environments, need for business agility and changing business dynamics, the open-closed principle makes a lot of sense. Organizational entities (teams, groups, process areas, departments, business units) should be closed for modification but open for extension. You should create these structures in such a way that you don't have to change organization or unit structures every time business dynamics and customer needs change. You should also be able to support changing needs by extending capabilities of existing structures.
3. Substitutability is derived from behavioural sub-typing in object oriented design. From the organization design perspective, ideally people in sub-units of larger units should be able to take the responsibility of a larger unit over a period of time if the situation demands it.
4. Interface segregation principle statutes that no client should be forced to use or depend on methods they does not use. This is directly applicable for organization design. The clients should not be forced to use processes, activities or methods that are not relevant to them as part of their service delivery mechanism. True extensible organization structure is where every customer of product or service feels that the whole structure is specifically created or customized for them.
5. Dependency inversion principle is based on cohesion and coupling. One of the key software engineering metrics for quality software is cohesion and coupling. Cohesion means the degree to which elements of modules belong together. Coupling means each of the components make use of little or no knowledge of definitions of other components. Although there are multiple factors that need to be considered in software design, you generally strive for high cohesion and low coupling. Organization process groups, departments and business units should also have high cohesion and low coupling. If two process groups, business units or departments require significant communication and interaction, those could be merged to create a single cohesive unit. Key considerations while designing these structures is that high level abstraction units should not depend on low-level units. Instead, both should depend on abstraction levels. Also, abstractions considered while building units should not depend on details. The details should depend on level of abstractions.
With these considerations, you can build a highly scalable and agile organization structures that provide sustainable competitive advantage for your business.