By Philip J. Gill
Choosing a client/server architecture
demands a strategic approach.
Two tiers or three? That's a common
question many information systems (IS) organizations must answer today when
building and implementing new distributed client/server applications, or
migrating existing applications. Unfortunately, the answer seems to get
more complicated every day.
Analysts say it depends on a number of factors, ranging from the number of users the architecture will support to the types of services it will employ or deliver to the application itself. And these days access to the Internet and the World Wide Web have to be taken into account as well.
In such a complex environment, it's wise to make sure you're asking the right question. Some observers say that the growing complexity of client/server applications, the sophistication of technologies available to build them and access to the Internet and the Web are rapidly making discussion of tiers irrelevant. Instead, these analysts say users should choose an architecture based on how well it can support the functions and services the application is to provide. "You should stop counting tiers," says Ken Sobel, senior analyst with the Hurwitz Consulting Group, a Newton, MA-based consulting firm that specializes in client/server application development tools. "The important thing is accessing data. It all depends on what you are trying to do with that application."
Hand in hand with this advice is the necessity of knowing your existing environment. Rich Ptak, director of systems management research at D. H. Brown Associates, a Port Chester, NY, research and consulting firm, warns users to take a careful look at the network in any decision to migrate existing applications from two to three tiers. For instance, Ptak recently consulted to a major hospital whose IS personnel were concerned about the performance of a critical hospital records system. To alleviate the mounting bottleneck, they had decided to upgrade their existing 32-bit servers and buy new 64-bit systems, migrating from a two-tier to a three-tier client/server environment in the process.
But Ptak did a study of the application's performance and all the component parts, including the desktop, server, network and high-speed disk drives. He determined that the real problem wasn't with the desktop systems or the servers IS wanted to replace, but with the high-speed drives. "They were attached to a bus that ran at higher address levels, so they didn't get accessed frequently," he explains. "We advised them to put the same high-speed drives at a lower address level. They did, and the bottleneck went away."
The lesson, says Ptak, is to examine all components of a client/server application before making critical decisions on implementation.
Before going any further, it's necessary to make clear that discussion of three-tier and multi-tier or n-tier architectures usually refers to logical software layers in an application, not how many hardware layers are involved. While a two-tier architecture requires two physically separate hardware layers--a client and a server--connected across a network, a three-tier or multi-tier architecture does not. The term three-tier is a logical, not a physical, distinction. Of course, many IS organizations implement three-tier or multi-tier applications using dedicated hardware at each layer. But it is not uncommon for user organizations to implement both the middle (application and business logic) tier and the top (database server) tier on the same physical hardware, which is often a Unix-based symmetric multiprocessing (SMP) system. Servers based on the Microsoft Windows NT operating system are becoming popular for low-end and departmental applications.
As a general rule, analysts say, small departmental client/server applications probably will continue to be two-tier. Enterprise applications, on the other hand, will almost always be three-tier. Jay Prakash, president of Strategic Focus Research in Milpitas, CA, says the number one driver behind the choice of two-tier versus three-tier environments is user demand, not the size of the database or the application. To Prakash, it's a performance issue; when many users want access to the app and the data, the server may bog down. Performance improves when you separate application logic from the database onto separate tiers, either physical or software layers. If conversion to three tiers becomes necessary, it will be because the number of users attempting to access the application is increasing. For instance, a company that decides to expand a successful two-tier departmental application into an enterprise-wide application, increasing substantially the number of users who will access that application, should move that application to a three-tier environment.
Although two-tier client/server implementations outnumber the three-tier variety today, the trend is clearly toward more complex three-tier architectures. As little as two or three years ago, the Gartner Group, a Stamford, CT-based IT advisory firm, estimated that as many as 90 to 95 percent of all client/server implementations were two-tier. Those applications have a desktop "fat" client that contains presentation, business and application logic, connected across a network to a database server. But that preference is changing rapidly.
According to Roy Schulte, vice president of Gartner's system and software technology group, 40 percent of all new client/server applications implemented in 1996 used three-tier architectures. They typically had a "thin" desktop client that holds only the presentation logic, one or more middle tiers containing business and/or application logic, and a top tier of one or more database servers.
By the year 2000, Schulte predicts, 75 percent of all new client/server applications will employ a three-tier or n-tier architecture. He cites several reasons for the shift. First and foremost, IS organizations in businesses large and small no longer build core back-office applications, such as accounting, human resources, purchasing and logistics. Today, they buy them from a vendor of packaged enterprise software, such as SAP, Oracle, Baan Co., PeopleSoft and others. Most of these vendors have implemented their software for three-tier client/server architectures.
Second, even when IS builds applications rather than buys them, many developers are choosing to build them in three tiers. According to Schulte, many of the most popular client/server application development tools--Sybase's PowerBuilder and Microsoft's Visual Basic are two examples--were capable of building only two-tier applications until recently. So no matter how much the IS organization might have wanted to go to a three-tier approach, their development tools forced them into a two-tier implementation. In the past year or so, most of the leading development tools have incorporated at least limited support for three-tier architectures.
Third, Schulte says, there are advantages to implementing applications in a three-tier environment. These advantages include the ability to mix systems with many applications, to combine data from two or more sources, to easily update or modify the application, and to accommodate a high transaction load. (For other examples, see "When to Build Three Tiers.")
Some of the more trendy application areas are also prompting the general move toward three-tier architectures. For example, Sobel of Hurwitz Consulting says it's probably better to implement data warehousing and data mining applications on three tiers. "These applications involve very complex queries," he explains. "You're probably better off implementing them in a three-tier environment so that these complex queries don't bog down the main database." However, he adds, "Many sophisticated users of these applications are doing fine using two tiers."
Many first-generation Internet and Web applications were two-tier, says Schulte of Gartner Group. They typically involved a Web browser running on a desktop client and a Web server connected across the Internet. However, as many companies add back-end databases, these sites are expanding to three tiers or more. "The Web greatly accelerates the use of thin clients, which is a characteristic of three-tier architectures," he says.
As popular as three-tier environments are predicted to become, not all benefits accrue to them. "You have greater flexibility, resource management and robustness in a three-tier environment, but you also have a greater level of complexity," says Ptak of D. H. Brown. Hence, three-tier architectures are more expensive to build, take longer to implement and are more difficult to manage.
In contrast, two-tier architectures are cheaper to build and quicker to implement, because, among other things, there are fewer logical software and physical hardware layers. Users ought to weigh the advantages versus the drawbacks, to make sure the added cost and complexity of a three-tier architecture are justified.
Because of the complexity of three-tier and multi-tier applications, analysts say they're impossible to implement without a middleware layer to manage them. "The more you put pieces of an application in different places, the more you need some form of middleware to manage the complexity of the system and to communicate and coordinate between them," says Sobel.
He adds that middleware also makes client/server applications easier to manage. For instance, in a three-tier architecture, software updates--a common systems management task--can be accomplished more easily than with two tiers, since the application is more modular and logically isolated. Changing one component will have fewer consequences for other components in such an environment.
What form of middleware that three-tier client/server application requires will depend, once again, on the application needs. Transaction processing (TP) monitors are best suited for transaction-oriented applications and may not be optimal for all three-tier environments. Messaging systems, remote procedure calls (RPCs), database connectivity tools and object request brokers (ORBs) are other common types of middleware available from third-party vendors. But analysts say they've also seen users implementing middleware-type functionality using technology such as the sockets in a TCP/IP protocol stack.
As noted earlier, some analysts believe that users shouldn't get hung up on the idea of tiers. Hurwitz Consulting advocates a concept called "hyper-tiers," in which the number of tiers or logical software layers an application requires is completely transparent to the user. To users, Sobel says, the complexity appears as a series of services available over the network.
Leading the way to this concept of hyper-tiers is the Internet and Web. "If you're surfing the Net, there's no telling how many computers you could be going through before you reach your destination," Sobel says. "You could be passing through a dozen computers all over the world."
On a departmental scale, the so-called hyper-tiers will appear as dedicated servers that provide specialized services. For instance, Microsoft's ODBC middleware is commonly used to access multiple databases. Increasingly, ODBC drivers require enough overhead that it makes sense to move them from the desktop systems to dedicated servers that provide nothing but ODBC services to all users on the local-area network (LAN). Visigenic Software of San Mateo, CA, and Intersolv of Rockville, MD, provide tools to build these ODBC services on servers.
Sobel believes that users will move other commonly shared services off desktop clients and onto dedicated servers. "It's easier to manage and administer these systems if the services are located centrally, rather than on every desktop."
Gartner's Schulte also downplays the concept of two versus three tiers for IS departments and developers. "Developers must consider each application and make the choice between two-tier and three-tier designs on a case-by-case basis," he says.
Instead of using tiers as a model, the Gartner Group identifies six modern IT software architectures for distributed computing systems, classified into two major types: function-oriented architectures and data-oriented architectures. Each of these two categories, in turn, contains three model architectures.
The first of the function-oriented IT architectures is, of course, two-tier and multi-tier. Two-tier architectures, in Gartner's view, are and will remain the "preferred choice for most decision support tasks and for simple, small- to medium-size departmental jobs. Large or sophisticated production applications have always been multi-tier, and the trend is for more midsize, moderately complex applications also to use the multi-tier configuration."
Service-oriented architectures, Gartner's second function-driven category, are a particular type of multi-tier environment that allows multiple, related applications to share application logic and data. This architecture assumes multiple software tiers and usually has thin clients and fat servers, with little or no business logic on the client.
This particular architecture gets its name from its structure. "A service-oriented architecture leverages the principle that many aspects of processing are inherently tied to the data rather than associated with a particular application," a Gartner report explains. "The code associated with a specific task is organized as a modular 'service' that can be invoked by one or more 'requestors,' or software 'client' programs."
A service-oriented architecture also assumes that the different but related software functions have common, predetermined interfaces that facilitate the sharing of application logic and data among multiple, related software functions.
In contrast, the third functionally driven IT architecture, the message broker architecture, assumes that no such standard interface exists between applications and that a neutral intermediary--in this case, a message broker--is required to facilitate communications and data exchange between applications. Any application relying on message brokers is inherently a three-tier or multi-tier environment, says Gartner's research. Message brokers act as hubs that copy and resend messages to one or more destinations. In the process, they receive messages in one format coming in and reformat them according to the needs of the target system before resending them.
Gartner's three data-oriented architectures are database gateways, data warehouses and operational data stores. When it comes to two tiers versus three, these architectures have a common trait: Depending on the circumstances of the particular application, all can be implemented in two-tier or three-tier configurations.
Many users probably think that database gateway is intrinsically a two-tier architecture. But Schulte says it can be either, depending on the needs of the particular user organization. While most may be two-tier, this architecture can have three or more tiers when more than one kind or brand of database are involved.
The other two categories, data warehouse and operational data store, are used for complex decision support and production online transaction processing (OLTP) applications, respectively. As such, they can also have either two or three tiers. Again, that decision depends on a number of factors in Gartner's list, such as number of users, number of applications or volume of transactions. For instance, an operational data store that supports more than 10,000 transactions per day would be better suited to a three-tier environment. In a two-tier environment, the database server would quickly become a performance bottleneck as it got tied down servicing both transaction requests and database updates.
The bottom line for IS organizations today, say analysts, is that no one architecture will suffice for all application needs. The best course is to choose what's best based on the functional and/or data needs of the application, not on the number of logical software tiers. Indeed, analysts say it's likely most companies will have a mix of IT architectures. Two-tier and three-tier configurations are complementary, not competitive and exclusionary.
Philip J. Gill is a free-lance writer and editor based in San Diego. He can be reached at philipgill@aol.com.