Many early business applications were written for a single dumb terminal connected to a process running the program on the computer. These applications typically shared data with other applications through the file system or database. Each user required a separate process, and that process ran a copy of the entire program. This implementation was relatively simple to construct. However, it became inefficient as the number of users increased, and it posed problems in scaling beyond a single computer.

To increase efficiency and performance, many systems insert a transaction monitor, which allows developers to divide the single application into a number of servers. These servers can then be distributed across multiple computers. The user can run a smaller program than could be run without the transaction monitor, while the program shares servers with other users on the system, thereby promoting efficient use of system resources.

Figure 1. Process per User Model

The transaction monitor is also responsible for coordinating database updates across the servers used in a transaction. For instance, when a CSR creates a new customer account, the application might use multiple servers to update the database. One server may handle the customer information, and another server may handle the products and services purchased on the account. The transaction monitor ensures that all servers complete their update successfully; if one fails, the other servers roll back the update, leaving the database unchanged. This action maintains consistency within the database.

Figure 2. Transaction Monitor Model

Along the way, the dumb terminals became more intelligent. These newer smart terminals could enforce restrictions on data as the user completed each field, enforcing requirements that the keyed-in data be numeric or alpha, for instance. Some terminals collected an entire screen of data before sending it to the program, thereby minimizing communication traffic with the computer.

As the personal computer (PC) proliferated in the early 1980s, moving business users' applications to the PC was a natural extension. PCs displaced many smart and dumb terminals, in some cases, simply using terminal emulators to run the same applications as the terminal they replaced. Early PC applications followed the model of running a single process on the PC while relying on the database or file system to share information.

In the 1990s it became common to connect PCs to a LAN. The LAN enabled PC–based programs to follow a model similar to the transaction monitor. In this model, the work is split between a client, a program running on the PC that is responsible for display and data entry, and a server that is responsible for the business logic and database storage. This architecture is commonly called client-server. One challenge introduced with client-server applications is that of keeping the software versions on the numerous clients in sync with the software versions on the server. When the server software is updated, all the clients must also receive an update.

To improve the performance and scalability of these client-server systems, three-tier architecture became popular. In this architecture, a tier is a layer of software. Three-tier architecture can be defined in many ways, but the most common places the user interface in the top tier, the business logic in the middle tier, and the database server in the bottom tier. Note that this is a logical partitioning of the system with clear interfaces between the tiers. Many three-tier systems are physically implemented on one or more machines. A common implementation places one large single or multiprocessor machine in the bottom tier as a database server, a small number of middle-sized machines in the middle tier as business servers, and a large number of PCs (one per user) in the top tier.

The PC also brought another significant trend into the mainstream: the GUI. The GUI significantly changed both how users interact with the program and how developers design and code the programs. Rather than scripting a transaction by filling in fields or screens, GUI applications are event driven. In event-driven systems the software does not dictate the next action for the user; instead, the user selects the next action by a mouse gesture such as clicking a button, choosing from a pull-down menu, or double-clicking on an object. This approach allows more flexibility for the user but requires more complex software that cannot make the same limiting assumptions that scripted applications employ.

For example, a scripted application might force the CSR, when creating a new account, to get the service address, customer information, services, and installation appointment in exactly that order and validate the data along the way. A GUI would allow the CSR flexibility in the order that the information is gathered to match the flow of conversation with the customer. The GUI must then validate not only the data but also the assumptions that used to be handled by the scripting. For instance, because the service address may be entered after the services desired, is the service available at the customer's address?

Viable software architectures have many variations. This brief overview only discusses the basic concepts as they relate to a few of the viable Intranet software architectures.

Figure 3. Three-Tier Architecture