Let's face it folks, there are a lot of failed client/server projects out there. Although a few project failures are unavoidable in the world of software development, most of the failed client/server projects that I've seen can be traced to a single common problem: bad architecture.
In the world of client/server, architecture is everything. It's the way we apply technology (hardware and software) to solve a specific business problem. At the same time, we must keep cost and other resource constraints in mind. If significant mistakes are made at the drawing board, the project runs an even greater risk of failure because of technology or cost limitations -- the two surefire client/server killers. This month, I examine some common mistakes that client/server architects, designers, and developers make when creating a client/server system architecture. Also, I show you how to prevent each mistake from becoming a part of your client/server project.
For example, a few years ago a team of consultants had to create an inventory control system for a small computer distributor. Rather than spend time defining the business model, rules, and requirements, the team dove right into the development of the application. The team pieced together hardware and software components based on one consultant's understanding of inventory systems from a previous job site. The work was done away from the end user, and after six months the system was complete and ready for testing.
The system did not live up to the processing load or the business requirements of the distributor during testing. The consultants had basically guessed at what system architecture to use. Needless to say, the project was considered a failure, the consultants were fired, and the business was left without a system. Everyone lost.
Client/server architects need to crawl inside the business requirements and understand every aspect of the problem that the system must solve. Components of the problem include the number of users, type of processing, cost constraints, performance requirements, and business rules, just to name a few.
The trend of prototyping your way through a client/server project produces mixed results. Although prototyping does involve the user and is thus a great way to gather requirements, you can also find yourself in the "prototyping death spiral" where iteration after iteration of a prototype leads to a final inefficient and unmaintainable application. Also, tools that are suitable for prototyping often can't scale. The trick is to use a prototype but not to neglect a sound application design and practical architecture.
For example, Distributed Computing Environment (DCE) is a popular, industrial-strength heterogeneous middleware layer that many architects use to link platforms together. However, architects often fail to select the development tools that can use DCE, define how DCE will link to particular database servers, or even check to see if DCE is available for all of the platforms in the architecture. The same goes for message-oriented middleware (MOM) products such as Peer Logic Inc.'s (San Francisco) Pipes, ORBs such as Visigenic Software Inc.'s (San Mateo, Calif.) VisiBroker for C++ (formerly ORBeline from PostModern Computing Technologies, which merged with Visigenic in the spring of 1996), OLE automation servers, TP monitors such as Novell Inc.'s (Orem, Utah) Tuxedo, and other third-party middleware layers.
The fact is, tools, middleware, networks, and databases don't always work and play well with others. Leaving out the details causes problems as developers attempt to integrate software and hardware components in the final hours without a clear and detailed understanding of what they need to integrate.
For example, I worked with an organization that was a self-declared "Visual Basic shop." However, Visual Basic was only a good fit for 75 percent of the projects, and thus the other 25 percent failed. The organization had picked Visual Basic because the MIS director saw a "neat" demonstration once at a conference.
Architects always need to go from the requirements to the tools, not from the tools to the requirements. The process of tool selection is a logical one, using the technical criteria gathered at the requirements stage. Using this criteria, architects can select a few candidate tools and then evaluate each as to its ability to meet the requirements. This process should take place in the middle of the project, not at the beginning.
For many of the multi-tier client/server systems I've encountered, the use of three-tier or n-tier architecture is overkill. The systems use one tier too many, and here's why. As I've mentioned many times already in previous columns, the problem that three-tier and n-tier architectures solve is the ability for a client/server system to scale to the enterprise. Usually this means handling more than 100 concurrent users, but the number can vary depending on the processing load that each client places on a system. Simply put, by moving the processing to more than two tiers (having at least one machine act as an application server), client/server systems can scale to any number of users and to all sorts of processing loads.
Sometimes a multi-tier architecture is a requirement on smaller systems if special circumstances exist -- for instance, the requirement for real-time processing, or an extremely high-volume OLTP system. Sometimes there is a business reason to place the application logic on a central server, but a two-tier architecture can handle this as well, through stored procedures or triggers. I'm finding a number of client/server systems that have only a handful of users and no special circumstances and that leverage three or more very expensive tiers unnecessarily.
Let's get this straight. Although it is useful in a few cases, multi-tiered client/server development is significantly more expensive and more difficult to build than traditional two-tier. Thus, multi-tier architectures are only a consideration when you support a large user load.
Unlike the more popular two-tier world, three-tier developers can work only with a few tools (such as EncinaBuilder from Powersoft, JAM/TPi from JYACC Inc. [New York], Forté, and Dynasty) or 3GLs such as C and C++. In addition, when developing in a multi-tier environment, developers can't work directly with the schema (in most cases) because it's hidden behind the middle tier (such as a TP monitor). As the number of links in the client/server chain increases, so does the number of single points of failure, and the number of vendors involved can make integration difficult. All of these issues can double the cost of the technology (cost of the tools, servers, components, and so on), as well as double the development time. The rule is: If you don't need three-tier or n-tier, don't use it.
The benefit of a fat server is that by placing the majority of application processing on the database server, you free up the client. In addition, because the processing takes place on the same machine as the data, there is a reduced load on the network. Placing the logic on the server also simplifies the process of changing an application because the program logic is centrally located.
The tradeoff comes into play when you consider the number of users your database server can support. For instance, a simple two-tier fat client system may only require an average of 2 percent of a database server's capacity per client. In contrast, a similar system that uses a fat server architecture may require an average of 5 percent of the server's capacity per client. If you do the math, you realize that the fat server system supports 30 fewer users. You can scale better by distributing the processing to the client PCs.
The fat client movement currently drives many client/server architectures, including a system I saw built to process invoices. Using an Oracle database, the architect had the developers place the majority of the application logic on the database server. The system supports 50 users, and they soon found that the server reached capacity during normal processing at around 25. To increase the system's capacity, the system had to be rewritten so that the majority of the application logic resided on the client.
Clearly there are business reasons to create a fat server, which can place constantly changing application logic in a central location. Such placement cuts down the number of times you'll have to visit a client's PC to update program files. However, you do so at the expense of capacity. I'm finding that you generally have to change the application on the client anyway when you change stored procedures or triggers. Stored procedures and triggers are proprietary and usually procedural in nature.
If you need to update the application logic constantly, you may want to consider an automatic application-update mechanism. Although these mechanisms can be difficult to develop, it's really just a matter of having your application check for a new file on the file server or a new BLOB in the shared database. Then download and automatically install the updates. The architectures of Java and ActiveX have already mastered automatic distribution, and there is no reason that other tool vendors can't follow suit.
Although everyone wants the most advanced system possible, attempting to implement unproven technology can stop a client/server project in its tracks. Products are delayed and capabilities are downsized or never released at all. Recent client/ server history includes many instances of this syndrome. My best advice is, unless special circumstances exist, build your client/server system with only shipping products.
If you've made any of the mistakes I've discussed in this column, don't panic. Learn from what works and what doesn't. Client/server technology changes so rapidly that architecture is more of an art than a science. Still, it's your responsibility to design a system that not only works but provides the best value to your clients. And we all know what a difficult goal that is to achieve.