The topology of a local area network is very much determined by the structure of the development organization, and by the size and nature of the projects undertaken by that organization. The techniques of LAN installation, configuration and management are beyond the scope of this document. However, it is possible to formulate some simple guidelines which facilitate management of the development process.
Local area networks are typically divided into logical partitions known as domains. A domain is defined as a logical subgroup of a network, which contains a defined group of network nodes (machines), a defined set of network resources such as shared disks, directories and printers, and a defined set of authorized users. Each domain thus forms a logical network in its own right, and multiple domains may exist on a single physical network. A domain may include resources residing on multiple network server nodes, and multiple domains may access the resources of any particular server. Each user on the network is provided with a unique user ID and password. An application developer may be defined as an authorized user of multiple domains within the same physical network; the same or different user IDs and passwords may be used. Figure "Network Domains" illustrates a network with three domains, each containing a number of network nodes. Each domain has one or more server nodes (marked S) upon which reside shared resources accessible by users on other nodes. Note that the servers may be accessed from within a single domain or from multiple domains, and that other network nodes may also belong to multiple domains. Note also that there is no direct mapping between a network node and a network user; a user may, in principle, sign on and access server resources from any network node in the domain.
Assuming a project-team orientation in the development organization, it is expedient to logically group the members of a particular project team, in order that they may be treated as a distinct group and separated from other project teams for purposes of resource access and administration.
In the simplest case, a number of project teams in the same physical location would use the same physical network, partitioned into separate domains for each project team. Each domain would possess its own set of production libraries for application resources; other development resources such as compilers and generic code libraries, which are common across the entire development organization, would be stored in a production library on a single server, and defined within all domains. This technique provides isolation of application resources while also allowing common access to other development resources, and eases the task of maintaining and updating these common resources since only one copy need exist on the network.
The principle of one domain per project team is obviously a "rule of thumb" and must be evaluated in light of the individual development organization. In the case of very large projects, it may be necessary to subdivide the project team into manageable subgroups. This would probably be necessary purely for managerial purposes, irrespective of whether a LAN were to be used. Conversely, very small project teams may not warrant the effort of establishing a separate domain, and several such small teams may be combined in a single management unit with a single network domain.