The tendency of a good developer is to make an application as efficient as possible. Minimise communications, use memory rather than disk for storage and generally make things as tight and self-contained as possible.
Efficiency is not scalability and developing an efficient application often runs counter to making a scalable application. Scalability is the ability to inexpensively grow to meet increased demand. It follows that, efficient applications do not necessarily support increased demand.
Let’s consider a sample efficient application. It confines a data processing task to a database that holds the data to be processed, in the form of some stored procedures. This approach has the benefit of reducing communication and shields the implementation of the process from the other tiers of the application.
Unfortunately, in enterprise applications, data processing applications are rarely simple. We all know that stored procedures are pretty bad as a programming medium (bad testing, debugging and IDE support, together with a nasty procedural syntax 
). We also know that programs in a database can perform pretty poorly with all that context switching.
While efficient, such an approach will not scale well. A more scalable approach is to process the data away from the database and return the processed data back to the database. This is not efficient, requires configuration, and generally more trouble.
However, efficiency is not the purpose of this approach, scalability is. If each task can be broken down into discrete sub tasks, they can be split and parcelled out to many “cheaper” processors and hence your task becomes scalable. With the advent of Multi-Core technologies, this approach becomes even more attractive.
[tags]IT,Enterprise Applications,Scalability,3 tier[/tags]
