All parts of BAPO^[1]BAPO model explains how the business, architecture, process and organization should play with each other in a SW organization. I like it personally, as it helps me explain several things such as … Continue reading have a home turf of problems/aspects/challenges it can address efficiently. For instance, maintainability is best addressed in the architecture, rather than some complex maintenance processes or special teams designated in the organization. In most cases, modifiability is best first addressed in the business, where only the essential modifiability is prioritized and rest is eliminated to save on complexity. Knowhow management and regulations etc. are mostly best addressed in the organization and process areas. While some technical risks are best addressed in the architecture, I was surprised to hear of a case where the business people covered against a risk by just arranging an insurance, thereby relieving the architecture of the complexity.

However, most organizations have an imbalanced set of strengths. Some have very good business developers, some great architects, some very careful process people and some very talented line managers. This implies that the organization will be inclined to stress some parts of BAPO more than necessary. For instance, you may come across a 50 page document explaining the bug handling process, or a regularly meeting high-level change control board trying to assess the impact of upcoming changes by the number of changed lines or such irrelevant measures. So, the imbalanced set of strengths of the organization causes some of the BAPO to overextend from its home turf to other areas, where it’s not really efficient.

I don’t have a complete solution. Two things that could help: (1) ensure that people in the organization are respecting and willing to work with people from other disciplines; (2) watch for the imbalances in the organization and apply counterweights in the devised solutions.

What other elements could help in the solution?