Modularity is about business processes as well as software or system design. The Innovator’s Solution (Clayton Christensen, Harvard Business School Press) analyses this very well, identifying modularity as a phase, or more accurately, a state in the going development cycle.

Choosing modularity as a core objective, as many appear to do these days, does not appear to be effective. Trying to make something modular when the subject is not fully understood and the interfaces not clearly defined and predictable can be fatal.

When, in order to make a product or process good enough in the current state of its market, it needs to be tightly integrated… then that’s the way to go. The system will evolve to a point where modularity at that point makes sense (for a period of time), with tightly bound sub-systems.

Looking at products (including software), consider the business processes in the market. For instance, the packaging (not necessarily physical, but documentation, support and other services) and other logistics are also part of the whole, and may well be suited to modularity (e.g., one company offering support for a product that’s built by another) even if the product itself is tightly integrated at that point in time.

In summary, modularity is not better or worse than integration. Each has its place, depending on the state of the market/ecosystem where the process/product/service operates. Part of a system can be in a modular phase, where another part of the same system needs integration.