Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Oracle and PICK

Re: Oracle and PICK

From: Dan <>
Date: Sat, 17 Apr 2004 22:12:14 GMT
Message-ID: <2Zhgc.5856$>

"Ross Ferris" <> wrote in message
> Imagine for a moment that you head up an IT department of, say, 100
> people, and the company is looking at 2 alternative solutions.
> The feature set of both products is similar, performance is similar,
> even pricing is comparable. As head of IT, your COO and CFO ask you
> for a technical appraisal of both solutions.
> You look under the hood and discover that Option 1 has the potential
> to reduce IT staff numbers to 10% of there current level ! That's
> right, your department will shrink from 100 to 10 over the next 18
> months by all accounts, as there are similar sized comapnies using
> this application with much smaller IT staff numbers.
> Option 2 on the other hand will guarantee that the current staffing
> level of 100 will remain over the next 2 years, and indeed may need to
> be increased with a few additional DBA's.
> Now, YOU have to report back to the CFO & COO --> do YOU do the
> honourable thing & fall on your sword and have Option 1 installed, or
> do you look out for NUMBER 1, and install Option 2 ... and be honest
> to yourself here .....
> Yes, TCO is relevant, but while ever there are empires at stake,
> people will man the battlements and strive to save the empire - and
> don't feel too bad, it's human nature !
> --------------------------
> If you look @ TCO for an installed solution, obviously there are
> certain TCO elements that would remain constant. If you have a site
> with, say, 500 PC workstations deployed across the country running
> Win2K & XP, then the infrastructure & support costs with ANY solution
> will be more or less constant
> (OK, so Nick would deploy "green screens" rather than PC's, so users
> will not stuff up windows, there will be less time lost with
> "futzing", and fewer moving parts so one would assume less failures
> --> but lets discount that Nick !)
> So, to simplify the calculation, lets assume we are dealing with a
> centralized server running some *nix variant (or Windows if you
> prefer!)
> The calculations should be fairly straight forward - we are dealing
> only with cost of acquisition of hardware & software [not applications
> - I've already pegged those as constant for this example, but if Nick
> is able to sell a solution at 1/4 the price of an Oracle based
> solution, that obviously WILL have an impact on acquisition costs !],
> ongoing maintenance (including care & feeding of the DB environment).
> For the sake of this exercise, maybe consider a "hypothetical"
> application of reasonable complexity that contains around 1,000
> tables.
> Should we add in development costs for, say, making enhancements to
> the base system on an annual basis, as this is also an important
> aspect of TCO ? For the sake of my example, could we assume we are
> extending the base system "somehow" (each year) by adding, say, 24
> additional tables (2 a month may be excessive) with 10-20 fields each,
> enhancing 50 existing screen based processes, creating a similar
> number of new screens, and likewise amending & creating 50 reports.
> Would anyone care to give REAL/INDICATIVE staffing for either side of
> the equation ? and hardware size & maintenance costs for database
> (once more, lets assume application maintenance is constant .... sorry
> Nick!) - assuming a user load of around, say, 200, to keep life simple

Hi Ross.

You do make good points, but evolving business requirements and the adaptability/flexibility of the system seem to pose as great in not greater influences to TCO. A good example of why PICK might actually have orders of magnitude higher TCO in cases where applications share data or need to integrate can be found right in the comp.databases.pick newsgoup under the subject line, "Why meaningful Item ID's suck."

Pick is so bound by its physical organization, that changes to logical identifiers across a set of conceptually related items leaves it open to no other choice but to entirely redesign an entire system. In the case of the thread mentioned, the work was estimated to take nearly two years. Note that Dawn, in her concern for TCO, recommends to the OP, "Best wishes and make 'em pay". I'd recommend reading the whole thread to anyone who is interested.

This makes as good ancedoctal evidence anything else.

I'm refraining from posting a URL to the referenced thread because it might be unacceptable to those netizen police out there that find excessively long URLs in newsgroups are impolite.



> Rather than emotive half truths, we should be able to get some form of
> quantification here ..... trim your hardware to the bone, be honest
> with yourself, and lets see some hard facts guys !
> "Laconic2" <> wrote in message
> > You are right.
> >
> > But the point was raised that there was no data tocompare with, and
> > is. Of course, there is a great deal more to market share than TCO.
> > it's relevant.
Received on Sat Apr 17 2004 - 17:12:14 CDT

Original text of this message