Problem solve Get help with specific problems with your technologies, process and projects.

Moving from a centralized data processing model to the client/server model?

What are the major considerations in moving from a traditional centralized data processing model to the client/server model in an organization?
Well, my first question, why move to client-server? Why not move to n-Tier architecture? The advantages of client-server are far outweighed by the advantages of n-Tier. Here is the difference in a nutshell:

Client-server applications move some of the processing power and business logic from the central computer to the client computers. This was a great step forward. There are some issues, however. If you want to make a change to the business logic, you must roll out the application across multiple clients. That is non-trivial when you move more than a handful of client machines. If you have three or four thousand client machines it can be made into a horror movie.

n-Tier applications use at least three distinct tiers to divide application logic into. On the back end is the data tier. This is where the database is and there is very little if any business logic stored here. It is just data. In the middle we have the business logic tier. Here is where the action is. This tier knows how to access and process the data. This is where our business rules are and where most of the processing occurs. On the front end we have the User Interface tier. This tier only knows how to display data and provides a user interface into the middle tier. It knows nothing specific about the data or how to access it. Because of the abstraction provided by the middle tier, the use interface can be changed or another user interface can be added without changing the data tier or the middle tier.

That said, here are some things to think about:

1. Moving to a decentralized architecture means that you will need a different infrastructure. You will need to set up middle tier and a user interface tier (desktop application or browser-based). Therefore, you will need the hardware and network to support it.

2. You can keep your legacy data in the current application and connect to it with the middle tier. This means that your current application effectively becomes the data tier. This is a common scenario. You may find it helpful to supplement the legacy application with modern relational databases where it makes sense.

3. Strongly consider a browser-based interface. This makes it child's play to make changes to the user interface without rolling out thousands of desktop applications.

There are many considerations, which I could write a book about. One suggestion is to get help up front from an experienced company in designing your new architecture. Do it well the first time and you will save many dollars and have a foundation on which you can build confidently for the future.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.