Unless you work for a dot-com start-up that's only a few months old, your shop probably has computer equipment or software that's been in production use for years or even decades. Computers have been around for a generation now, and inertia and tightening budgets can discourage companies from getting rid of older equipment that's doing an acceptable job. But isn't there shiny new hardware and software out there that can do it better?
>
A student posted such a question to the Hardware discussion in ITworld.com's forums. He wanted to know how he should move forward; what he got was a debate about whether he should change systems at all. His question, and some of the responses, are reproduced here.
Do you agree that IT pros should try to adapt their equipment to current situations? Or is it sometimes a good investment to shell out for new equipment? Respond to these opinions in ITworld.com's forums!
Need help in choosing solution
zonathen: I am a student working on a senior project in which we are designing a new system to replace a legacy system running COBOL. The business process under review currently involves a single COBOL programmer; any changes to the actual rules need to be hardcoded every year. All data needs to be hardcoded as well. The process simply does some calculations and outputs the answers to a file for further manipulation and, ultimately, printing. The business wants to upgrade this process to a modern solution that doesn't involve a mainframe or COBOL; the new process should be easy to update and change when necessary.
We are thinking of getting a server and some type of SQL-based solution (the latter to allow for easy updating and retrieval of info). Which software package best fits this problem? And what is needed to calculate the figures and ultimately output them to disk? Microsoft SQL server? Access? Oracle?
Please help!
Are you looking for a solution to the wrong problem?
Brazee: The requirements you seem to have been given are to change two tools: your computer and your language.
The business needs of a company should not necessarily involve a change of tools. Instead, they should dictate that the company run effectively. Maybe the effective way of doing your job will include eliminating those tools. But eliminating them is not a business solution. And if you replace these tools without understanding what your real business needs are, you will fail to do the job right.
The first step in this job should be to find out what the true business needs are. Second, find out what problems the current tools are solving, and the costs of the current tools. Then come up with some alternate proposals, and compare their costs and benefits with your current situation. One proposal should be to enhance what you have now. Others should be partial and full replacements. Then all your proposals should be evaluated based upon the business needs -- not on the specs you list.
Forget technology: look at your IT organization
MooreEwing: The critical phrase in this question is "a single COBOL programmer."
Whether or not something is "easy" depends on whether you have people who know it. This company could solve its current problem with minimal technical change by hiring a second forward-thinking COBOL developer. Alternatively, its choice as to how to proceed could be determined by what other systems and skillsets are available.
If no useful people or equipment are available in-house, then the managers will need to recruit and buy, something which they do not seem to do naturally -- they allowed themselves to get into the singleton situation in the first place, did they not?
The one thing this installation should not do is go for a technolgy/product-based quick fix. The application sounds ideal for a rules-engine solution, but that would require investing in new people skills in enough depth to avoid possible repetition of dependency on individuals.
The second aspect of this question is: why change the hardware? What are the expectations of a new system -- cost savings? What will you save money on -- maintenance, software licenses? Or are you looking for scalability? Or aiming to move things to a single-function applicance server? Looking at this particular application without considering overall IT plans will result in what may prove to be a rather expensive cheap solution.
COBOL isn't obsolete!
JWeinblatt: Before you look to replace something, you should first learn all you can about what you have now. If you have COBOL code with hardcoded values, you have old-style coding. I have 19+ years experience writing COBOL code and could think of at least 6 to 10 different ways of coding a program that would be better than hardcoding values. I would suggest you look into to a DB2 table or any other database, JCL parm value, a sequential table file, or an 88-level value. Just because something is old doesn't mean that it is no longer of value. Do your research!
halpsy: COBOL is a modern solution and it can easily be updated and changed when necessary. You can use COBOL for an SQL-based solution to allow for easy updating and retrieval of info. You should look at a problem, analyze it, and select the best ROI solution before a priori throwing out the COBOL solution.
In fact, take a look at some of the Merant Micro Focus tools that are available to do exactly what you have been charged to do, but do it using COBOL. You might just enlighten your professor to the real world.
Get real, everybody!
jayscott: In any corporation in the real world, projects are initiated all the time for reasons far flimsier than this. While the previous posters are correct in their statements, they seem to inhabit an alternate reality where business managers make decisions for sensible reasons. Here's an attempt to be helpful in this universe, where decisions like this are often carved in stone by people whose ignorance is nearly complete. If your teacher is trying to teach you what the real world is like, she or he seems off to a good start.
When choosing tools (OS, language, etc.) you always need to consider the performance characteristics you will need in the system when it is running. Specifically, you will need to consider capacity, speed, reliability, and (most likely) cost. If your system must be cheap, but doesn't need to have especially large capacity, speed or reliability, a Windows solution (like Access) is probably appropriate. If your users will be looking for your head if your system needs half a day of downtime to rebuild corrupted indexes, or for yet another upgrade or patch, then you should be looking at a Unix-based solution (Sybase is now a nice choice for that). If you'll be pumping a terabyte or two daily into the thing, a mainframe with DB2 would be worth considering.
In general, the more capacity, speed, and reliability you need, the more you need to be using an OS other than Windows, and the more you will probably have to spend. I have installed very reliable but low-speed systems using very inexpensive PC hardware running Unix, and ultrareliable fast systems using Sun or VMS clusters. Microsoft does claim, these days, that it's possible to get excellent uptime using Windows 2000, but that's only by using a lot of machines, and assuming that the problems will only be in hardware: in truth, most problems are usually software, and software problems can bring down a whole cluster at once, so don't believe everything you read.
Resources
