Loose Interfaces

Cattle exiting through a "loose interface".

...sometimes architecture and organization are aligned in a particular manner (ConwaysLaw) because of geographical and organizational constraints. 

✥ ✥ ✥

To avoid development bottlenecks, we need to be able to limit the effect one team's work will have on another.

To help development of a system with many teams proceeding at a reasonable pace it is important to keep interfaces between systems somewhat flexible. This is particularly important in a situation where there are teams of developers that are geographically distributed (OrganizationFollowsLocation) and where rapid turnaround time for design and development is important. As an example, consider a project trying to build a prototype for an early customer demonstration to support a tender for bid. 

Communication is difficult. If requirements are changing and the teams are located in a variety of places then the poor communication can stall a project. This can be particularly problematic when an organization does not have an architectural center, such as described by ArchitectControlsProduct. 

This is particularly applicable in a research, pilot, or new technology application where teams are small, requirements are changing, and the potential for gridlock is great if dependencies are too high. There is typically an administrative or organizational center of the architecture, but does not always have the capability to design a complete system. 

Therefore: 

Limit the number of explicit, static, interfaces. Define large grained interfaces which allow developers to code against interfaces defined early, but which do not overly constrain functionality. Use LooseInterfaces like Callback, ParserBuilder and HierarchyOfFactories to achieve this. 

✥ ✥ ✥

Decoupling interfaces in this way will also simplify the development of EarlyAndRegularDelivery, since it makes it easier to build incremental systems. It can also make it easier to set up an environment where DeveloperControlsProcess by defining independent features at a small enough scale that they can be controlled by a developer or group. The end result is that as long as the components meet interface, quality, and other requirements, teams in different organizational units can implement them using any micro-process which suits them. 

Take care that the empire that supports the interfaces doesn't itself become a dominating focus that can drain project energy or create accidental coupling across the project. Brokers and other large communication frameworks have this danger. Keep the interfaces simple and in concert with business needs. 

Related Patterns: SubsystemBySkill addresses a similar situation, where the driving force is the skill set of the various teams.