How a poor business decision can lead to inferior technology implementation

Last week we were working with a large healthcare solution provider in the US who initially approached us to help them with some scalability and memory problems in their current system.
The client had migrated their solution from a COBOL- Mainframe solution to .NET+SQL Server, this was important since it reduced the TCO for their customers and their sales team were under tremendous pressure in the past selling a costly mainframe solution. However the business had not allocated enough time and budget for the IT team to do this migration. Based on the time and budget the IT group took the following route
· Move classic COBOL to NetCOBOL from Fijitsu – this was a good move since most of the COBOL code (millions of lines of COBOL) could be ported to .NET without much rewrite
· Moved data from flat files to SQL Server – done with good intension but to cut corners they migrated it in such a way that they would just use SQL Server as a store and leverage its indexing capability the SELECT queries being sent did not have JOINs (!!!) – all joins were being performed in the application tier. Ie multiple SQL SELECT queries were fired from the app tier to different SQL Server tables – the resulting data was manually joined within the app server. Huge number of .NET objects where created here.
· The front end for the application was written in VB.NET, however since they had to leverage the migrated COBOL code(Without code change) the front end would mimic the old mainframe dumb terminal which would not maintain state on their own and would require the server to maintain state.
· The remoting layer was implemented using client activated objects to facilitate state, the state was stored in app servers memory. The solution could not be scaled out because they had 2 problems
o Since the state was managed in the app servers memory the solution could not be scaled out
o Since the remoting was implemented using client activated objects (and not single call objects) it could not be scaled out.
They were getting an out of memory exception when they had 10-15 concurrent users but they were trying to sell the solution to a healthcare provider that needed a solution that could take on 100s of concurrent users – they were searching for a magic bullet that could fix their problem. Though we were able to identify the reason why they were running out of memory and make recommendations that could help scale the application slightly better without major code changes they can never meet the scalability requirements needed to make the sale.
Just another example of why companies should not give the technology decision to the business folks (the converse is also true :) ) . Had the company spent good time investigating the new technology and planned a good migration plan either on their own or with assistance from a technology partner they would not have faced this problem.