We define components, and build tools to manage them, in order to manage the complexity of software. One of the defining characteristics of software is its interconnectedness. Even relatively modest commercial systems may contain thousands of modules and scores of executables. Most of those thousands of modules depend on other modules. They can not be treated as autonomous elements of the product. This interconnectedness is one of the principle features that make the management of software and software development so difficult.

In the Foundry, each component represents a collection of related things. A module is a collection of files that represent the source code, test code, and documentation for a relatively small cohesive body of functionality. A module, however, may also refer to other modules, and, in the perspective of the Foundry the lower level modules it refers to are part of the higher level module. Similarly a program is a collection of modules and documentation files; and a system is a collection of programs and documentation files.

The power of the Foundry lies in the fact that each of these components is managed by name. If we extract a program we get all the files that make up that program, without citing them individually. If we request a build of a module as a library we get a compiled library (DLL) of the source code AND of the source code of any module that it may depend on – all by citing only the module name in the request to build.