The problem is at its most acute with thick client server systems where Rapid Application Development (RAD) tools have been used combined with a Relational Database. As the term implies speed and ease of development dominate at the expense of maintainability and scalability. This is acceptable in many cases when the application is straight forward and serves a specific function, but it becomes a nightmare in some business critical applications.
If you have reached this point with a Windows/SQL Server solution, what are the options for the future? None are particularly palatable and in the long term it is probably best to treat the current system as a prototype or legacy system and use it to buy some time for a complete redesign, but here are some other possibilities.
The simplest and cheapest solution is to replace the server PC with a far more powerful one. IBM, Compaq, Dell, etc. all make upmarket Intel computers which will run PC software. They are however engineered for the role of server. They have faster, multi-processor architectures, high bandwidth I/O, fault tolerance, redundancy, etc. They are naturally far more expensive than a conventional PC. A specialised NT server from Unisys is worth considering.
The weakness with the above recommendation is the continuing dependency on Microsoft software. At best this is reasonable, but it is far better suited to office applications than to business applications. Windows has an unenviable reputation for problems with reliability and security. In this case there is also a question mark over scalability.
A second alternative is to separate the server functions and to implement them on separate servers. This would allow some protection for failure of an individual server. The possible drawback is that it may be difficult to isolate the server functions without serious redesign of the applications. If redesign is considered then a far more significant change of architecture to a thin-client design should be introduced.
There is possibly some benefit to be gained from separating batch processing functions such as invoice printing to a dedicated server. Many applications today make far too little use of batch processing. It is not necessary to perform all functions interactively. Again the problem will be the need to modify the application.
It is desirable to move on from Microsoft software and to use more industry standard software. The majority of new applications today are developed using Java based Application Servers from IBM, Oracle, BEA, Cold Fusion, etc. These applications can be ported from one hardware and operating system platform to another, including Windows. However he Unix operating system is the best for the server but Windows is still the most common for the workstations. OS/400 is a wonderful server platform and IBM mainframes with z/OS would be the choice for many big systems.
Linux should be considered for the client machines, particularly for dedicated applications, but it won't run the Microsoft Office applications we are forced to suffer with. Consider it but be careful yet awhile.
If an Intel processor system is preferred then a version of Linux is the best option. It is essential to use only a supported version, not one downloaded from the Internet. Caldera (now SCO again) or Red Hat are leading examples, SCO Unix and UnixWare and BSD are other options.
A more expensive option is to use a specialised Unix server from IBM, HP or Sun, i.e. IBM RS/6000 (p-Series) with AIX. This will provide a definite expansion path.
The database is a problem area. SQL Server is dedicated to Intel/Windows servers. Oracle is the leading independent database software vendor, but in my opinion IBM's DB2 is probably a better option. DB2 is available on a number of platforms now. There are some serious worries about where Oracle is going in the future and they can offend customers!
If the change is made to Unix and DB2 or Oracle, then there will be a lot of modifications to be made to the existing applications. In theory all relational databases conform to the SQL standard, but in practice they have significant differences in the implementation, particularly in the handling of locking and stored procedures. The client/server APIs tend to be specific as well.
Martin Healey, pioneer development Intel-based computers en c/s-architecture. Director of a number of IT specialist companies and an Emeritus Professor of the University of Wales.