Slashdot Mirror
Oracle Investigation Grows
VValdo writes "Department heads resigning, millions of dollars wasted, documents shredded, the government investigating. No, it's not Enron-- as previously reported, the $95 million contract with Oracle is blowing into a full-fledged scandal in California, according to today's LA Times, The article begins, "California Highway Patrol officers moved in Thursday to halt shredding at the state's information technology department, and Gov. Gray Davis suspended the agency's chief amid a widening investigation of the state's multimillion-dollar computer contract with Oracle Corp.""
The guilty will be identified, heads will roll, policies revised...
In the end, nothing will change except it'll be even more difficult for California Departments to buy software than it is now.
Software licensing is really complicated. The typical bureacrat is just not up to it. If State Governments paid what Industry pays for IT executives, especially in California, there might be some chance that this kind of thing could be brought under control.
As it is, they'll just add more people to read over the contracts that none of them understand.
Even if they require contracts over a certain dollar amount to be reviewed by outside experts, the bureacrats will just start letting contracts just under that limit to lower their exposure to review.
I've been doing a simple analysis about switching us from Oracle to PostgreSQL. I came to the conclusion that, except for some of our GIS apps and data, we could recoup the cost of our licenses within 2 years. The cost involved with PostgreSQL would be training and re-writing vertical apps. Not paying license fees to Oracle *should* cover that additional cost and pain of migrating and re-writing. The whole reason I'm thinking about this is because of the California scandal. Those guys should really be tied to a post and whipped (not by expensive hookers either). Anyway, I'm actually going to do a more formal analysis of this starting today. Has anybody out there had any experience doing a migratin of this sort, for a enterprise of about 3500 PCs?
--- Think of it as evolution in action ---
The problem isn't that there is too much database technology that people don't understand, it's that there is not enough people who understand database technology.
I see this time and time again: organizations that have Access databases that multiply like rabbits. People have tons of "reports" that not really reports but data carrying instruments from one special purpose system to another, where they are rekeyed in and manually processed etc. The whole process, and many staff positions required by it, are essentially overhead; they are required for coordination but produce no value in themselves. People are satisfied, because they don't perceive all this as an expense, but part of the job description. Then there is a challenge that requires organizational change. They have to produce a piece of information that they didn't before; perhaps it is a new government regulation, or perhaps it is a new business venture. Several outcomes are possible: complete failure to respond, response in a way that is superficially adequate but involves inaccuracies or problems of timeliness, and finall and/or the accretion of another level of organizational cruft.
Of course databases are not a panacea; they don't solve this problem. But they are a critical parts of the solution. The purpose of database technology is to enable the re-use of information. If you have an independent business process with only a small number of well defined interfaces, that is supported by mature software, I agree there is little reason to reimplement using database technology. But a priori this is a bad, or at least a dangerous assumption. Starting from scratch the best solution when long term record keeping is needed is a relational database.
And database technology is not that complicated from a application developer's perspective. It dramatically simplifies most software problems that involve anything more than the most basic record keeping. It takes care of data integrity and optimization and many security and administrative tasks. Speaking as somebody who remembers the days when you commonly created your own on disk data structures with pointers, indices and whatnot, I know that 99% of the time I'm better of not reinventing the on-disk data structure wheel. How many novice written binary search routines do you want to debug in your life? How many pointer rebuilding routines do you want to have to code? How many times do you want to tear into live production code because of deadlock problems that didn't come up in testing? How many times should customers have to send data sets to their vendors to have the file structures rebuilt due to crashes or bugs?
Finally, with respect to Oracle, it is not the safest product in the world to let an idiot loose administering, but it's not friggin' rocket science either, unless your project requirements dictate complex DBA setups. In these cases not only is a solution like Oracle far better than what you could come up on your own, it decouples solving these problems from application logic, reducing development risks. For simple cases, Oracle scales down nicely if you don't get overeager about tinkering under the hood. If you have the licenses already (big proviso), there is practically no reason not to use Oracle for any application, no matter how small.
Of course if you have to use a server that is admin'd by somebody else who doesn't care if your project shrivels up and blows away, well YMMV. But that is hardly Oracle's fault.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.