Component-based Development and SOA

One approach to supporting smaller development teams is to use a component-driven architecture or a service-oriented architecture (SOA). With both approaches, each team is typically responsible for only a subset of the larger application.

If changes made to a given component or service enter a high-level application after the components are built and tested, other groups will only rarely break that a team's work — usually by changing interfaces. By isolating a typical build failure in the broken component, and allowing the rest of the organization to continue using the latest successful or tested build of that component, build failures are isolated to small teams, as discussed in the Small Teams section.

In the example above, a change to the Web UI would only result in that component building. If that build and fast tests passed, a build of the top-level order-entry system would be triggered to ensure that Web UI changes integrate into the rest of the components.

Often, that top-level project will provide only the smallest amount of glue code, and the packaging needed to neatly assemble the components. This not only isolates breakages to a component, but greatly speeds build times. In the example above, the Profanity Filter component does not need to be rebuilt every time someone changes a web page. As an added benefit, faster build times help keep the duration of a breakage short.

Componentized projects are also beneficial for smaller development teams. If a single developer on a team of 10 breaks one of the common libraries or services, it's likely that she is the only one impacted, and can fix the problem she introduced without catching the attention of the rest of the team. Teams do not need to be restricted to a single component to benefit from breakage isolation. Essentially, only developers actively working on any given component are directly impacted by its breakage, regardless of organizational structure.

Componentized projects support the first three pillars of pain free building: They reduce the frequency of build failures; the smaller component projects build faster; and failures impact a smaller number of people.