Re: Ideal mid-range server for Oracle?
Date: 13 Jun 93 21:17:32 GMT
Message-ID: <1993Jun13.211732.28635_at_qiclab.scn.rain.com>
jimh_at_carson.u.washington.edu(James Hogan) writes:
>Sorry to devolve into trivial hardware details, but am interested
>in obtaining your thoughts on good platforms for Oracle. We have
>a development server (Compaq Systempro) running Oracle under
>Netware. However, our estimates suggest that we'll soon outgrow
>the maximum capacity of its IDA disk subsystem
[...]
What follows is the original text for a column to appear in _The Oracle Integrator_ newsletter. It partially answers Jim's question.
Additionally, here are some brands and models I'd recommend: HP 9000, IBM RS-6000, Sun SPARCserver 1000 and SPARCcenter 2000, WYSE SMP boxes of various kinds, Sequent, Pyramid, and NCR.
--------cut-here----8<------
Picking the Perfect Database Machine
I'm working right now for the perfect client. Every consultant gets one occasionally -- a client firm that has hired consultants before, that knows what to expect and what not to, that is used to paying for quality and expertise, that is committed to making internal changes, that is investing in appropriate technology.
This client is a small firm, and they have almost no computing infrastructure, so they agreed to go with our recommendation for a computer to run the database server software.
So what were we going to recommend? Or rather, what was _I_ going to recommend? I was the one who got to make the recommendation -- with the understanding that whatever I said, would go.
A perfect client, as I said, but one that was quite willing to put me on the spot. If I picked wrong, it would be nobody's fault but mine. There were no artificial constraints on my choice, no requirement that the chosen box fit into any existing architecture -- there was no existing architecture.
In order to structure my investigation, I turned to CB-90.
The traditional CB-90 (Cost-Benefit analysis for the 90's) that Jack Keen taught me is geared for figuring out the best fit in a big, strategic project. This, however, was a small tactical decision. But I was able to adjust CB-90 to support me in several key areas.
If you recall my last column on CB-90, I said it offers a structured approach to decision making. It helps cut down politics, and creates an audit trail for the decision.
This time around, I found that it also cut the sales people down to size.
Step by step
First, pick your decision makers and influencers. Who are the people who have to believe in the decision? Who are the people who will try to scuttle the decision if they don't like it? (For me, this was a small group of senior people in the client organization.)
Second, get each of these people to commit three hours to help you with the decision. These will be three one-hour meetings.
Your goal here is to bring them into the process, and give them the choice to buy in to the process or not. [If you leave them out, they have every reason to question any decision you come to, since they didn't see how it got made.]
Third, ask each of them to spend their first hour _separately_ working up a list of things they want to see in an ideal system. In our case, it was the ideal open systems Unix machine to run a relational database management system. Add in your own concerns as well.
At the end of step three, here's what we had:
[ALBERT: PUT THIS IN A BOX LABELLED "FIGURE 1"] enough CPU power to meet our needs
128 meg of RAM
4 gig of disk
on-site service and support
reduced maintenance costs
reduced parts & supplies costs
upgradable equipment
open standards support (hardware & operating system)
open / POSIX compliant OS
vertical scalability, same OS
standard not open
able to support growth of company
better DBMS performance
support Symmetric Multiprocessing
vendor financial stability
application software lag time (e.g. Informix on Netware)
degree of fit with existing systems architecture
lack of needed products
lack of avail. talent lack of avail. training lack of avail. service, support
prolonged downtime
staff unfamiliar w/ technology
[ALBERT: END OF BOX]
As you can see in Figure 1, the written output from Step Three is just a grab-bag of issues. But an additional unwritten output is that your key decision influencers (if you've chosen cleverly they are the people who might otherwise be your political opponents) are not only brought into the process, they're also making the process more thorough.
For example, the CFO in our group was interested in both the up-front cost of the new system and its five year cost of ownership. That caused us to think about the dollar cost savings of a self-tuning Unix kernel (such as IBM's AIX), since it would likely save us maintenance labor costs.
Without the CFO's input, we probably would have taken such a feature less seriously, or lumped it in under a catchall "bells and whistles" category with no dollar impact. Instead, we put it under "reduced maintenance costs".
Sort and Organize
The fourth step is to take this list and group things together into these logical categories:
o Assumptions (optional)
o Hurdles
o Hard Dollar Tangibles
o Soft Dollar Tangibles
o Intangible Benefits
o Intangible Risks
Here is our output from this stage:
[ALBERT: PUT THIS IN A BOX LABELLED "FIGURE 2"] Hurdles
support SMP: enough CPU power to meet our needs
Hard Dollar Tangibles
128 meg of RAM
4 gig of disk
on-site service and support
Soft Dollar Tangibles
reduced maintenance costs
reduced parts & supplies costs
upgradable equipment (no box swap)
Intangible Benefits
open standards support (hardware & operating system) open / POSIX compliant OS
vertical scalability, same OS
able to support growth of company
better DBMS performance
support Symmetric Multiprocessing
Intangible Risks
standard not open (e.g. old VMS, MVS)
vendor financial stability
application software lag time (e.g. Informix on Netware) degree of fit with existing systems architecture lack of needed products
lack of avail. talent lack of avail. training lack of avail. service, support
prolonged downtime
staff unfamiliar w/ technology
[ALBERT: END OF BOX]
At this point, with Figure 2, you can see the similarity with the more traditional CB-90.
The "Hurdles" section is new -- it's where we put down our minimum criteria for what we would consider. Obviously we don't want to look at any under-powered boxes. We _will_ look at overpowered ones, trusting that their prices will keep us from going excessively up scale. (This turned out to be a safe assumption.)
Step Five brings you briefly into contact with each of your vendor candidates. Simply fax them Figure 2, and ask for
o their written statement that they pass your hurdles; o a dollar quote for the Hard Dollar Tangibles; and o a self-rating on a scale from 0 to 5 how well they provide the benefits (for risks, a rating from 0 to -5 on how much of a risk they pose to your organization).
They should add a brief paragraph or some bullet points explaining each line item. We're not going to necessarily believe their self-scoring, but it starts the ball rolling.
Step Six is my favorite part -- deciding just how important each of these issues is, compared to the others. This is the stage when CB-90 becomes a communication tool.
Here is where you cash in your second hour of each participant's time. Give each of them sorted list (Figure 2). Explain that they have fifty points to spend in each major section, and they should allocate the most points on the issues that they care the most about.
We hit our first snag here -- our Intangible Benefits section was subdivided into Business Issues and Technical Issues. Our business-oriented participants tended to want to spend all fifty of their Intangible Benefits points in the Business Issues half, and none in the Technical Issues half.
To get around this, we agreed that each subsection was to get 25 points, and people who felt our of their depth in either section could just leave that portion blank, trusting to the other participants to be aware of the relevant issues. If you don't have subsections, then this isn't as important.
To finish Step Six, gather together the separate weightings, and call in your last one-hour block of participant time. Then show them the numbers.
By all means, do NOT merely average out the numbers. It is far more useful to show the original numbers. Draw their attention to issues where everybody seemed to agree (all spending was about equal), and also to issues where there was noticeable divergence in opinion. In these latter areas, ask people to speak for their points of view, and encourage bargaining. Your goal is twofold: to get agreement on final votes (weightings), and to get communication between participants.
Ideally, the person who put fifty points on "degree of fit with existing systems architecture" can have a chance to explain the reason for that view, and can also see that other business concerns (such as "lack of needed products") may offset some of the perceived need for continuity in architecture.
Furthermore, it may be that an issue may turn into a hurdle -- that "degree of fit" might really mean to this participant "support for SNA", and any product that supports SNA is okay. If so, put the re-worded issue into the Hurdles section and move on.
Your outcomes are: final weights, and a real agreement from your participants that these weights represent the business needs of the organization.
[ALBERT: PUT THIS IN A BOX LABELLED "FIGURE 3"] [ PLEASE LINE UP THE COLUMNS THIS TIME! ] [ I SUGGEST YOU USE COURIER OR MONACO FONT ]
Soft Dollar Tangibles
reduced maintenance costs 10
reduced parts & supplies costs 10
upgradable equipment (no box swap) 30
===
50
Intangible Benefits
open standards support 10
open / POSIX compliant OS 5
vertical scalability, same OS 10
able to support growth of company 20
better DBMS performance 5
support Symmetric Multiprocessing 0
===
50
Intangible Risks
standard not open 5
vendor financial stability 5
application software lag time 15
degree of fit ... 0
lack of needed products 10
lack of avail. talent 0
lack of avail. training 0
lack of avail. service, support 5
prolonged downtime 10
staff unfamiliar w/ technology 0
===
50
[ALBERT: END OF BOX]
Now you're ready for Step Seven: grilling the vendors. (Tip: do *not* show the vendors your real weightings from Step Six.)
By now they've finished with Step Five, and you should have a spreadsheet ready to plug in YOUR VERSION of their numbers. For example:
[ALBERT: PUT THIS IN A BOX LABELLED "FIGURE 4"]
Intangible Benefits WGTS Box A Box B
=================== ==== = === = ===
open standards support 10 5 50 4 40
open / POSIX compliant OS 5 5 25 4 20
vertical scalability, same OS 10 5 50 5 50
able to support growth of company 20 4 80 5 100
better DBMS performance 5 3 15 3 15
support Symmetric Multiprocessing 0 5 0 0 0
== = === = ===
50 220 225
[ALBERT: END OF BOX]
In order to get these ratings for Box A and Box B, I took the short explanations each vendor gave for, say, POSIX compliance:
Vendor A: "Our OS has been licensed by the POSIX committee for the SMP
version of POSIX, and is currently certified as level 2
compliant. We think we should get 5 out of 5."
Vendor B: "Our OS is certified as POSIX level 1 compliant"
After a couple of phone calls to each vendor, along the lines of "Gee, the other guys say they're 'certified level 1' -- so why wouldn't that make them a 5 out of 5?", I was pretty comfortable with my ratings. Just to make things auditable, I wrote up my own summary for the scoring of vendors on each line item, such as: "The highest score for POSIX compliance will go to a product that is certified as POSIX level 2 compliant."
I had no difficulty getting the vendors to provide white papers and experts to defend their versions of reality, and the framework of CB-90 kept the mass of data under control.
It was also during this period that the sales people all wanted to take me to lunch. Just to be fair, and to stretch my lunch money, I said 'yes' to all of them.
Several of them double-teamed me, with a technical person to argue definitions and provide backup for sales claims, and a sales person to cast Fear, Uncertainty, and Doubt upon the proceedings. I had a blast.
Sales Person: "You see, we have this self-tuning OS kernel-"
Me: "Yes, I know. I gave you a five out of five on Reducing Maintenance Costs, partly because of that. You also posed less of a risk in Prolonged Downtime, down to a risk of negative one. Do you think your self tuning OS kernel should touch any other line items than those? Should it affect these lines more?"
Sales Person: "I suppose not." <looks to Tech Person for help>
Tech Person: "Did I mention that we're certified POSIX Level 1 compliant?"
And so forth. The food was good, too.
The ground rules for you during Step Seven are:
o anything the vendor wants to say must be put in terms of the CB-90
line items;
o encourage vendors to question your hurdles (see below);
o encourage vendors to suggest new line items (for example, we forgot
in our original bid to ask for a tape backup device);
o encourage vendors to shoot each other down (careful here!).
Vendors Help
We found the vendors to be very helpful, so long as we kept control of the conversations.
One vendor had only a uniprocessor RISC box to bid for our size of application. We had a hurdle that said "box must support Symmetric Multi-Processing (SMP)". He questioned why we needed SMP, really.
Well, SMP gives me scalable power, right?
He demonstrated that his uniprocessor (the IBM RS-6000 500 series) could outperform several of the SMP boxes I was considering with up to three and four CPUs. He could upgrade me to an 800 series and outperform the other guys at six and seven CPUs. And he could move me up to a huge SMP version of his box if I needed even more than that in future.
In other words, I had been over-specifying. I didn't need SMP. I needed "enough power". So I rewrote the hurdle to say "must have enough power".
More Info
If you have questions or need more info on Tactical CB-90, you can call me at 503-778-7973.
- Thomas Cox
--
Thomas Cox DoD #1776 '91 CB 750 Nighthawk tcox_at_qiclab.scn.rain.com
The Platinum Rule: "Do Unto Others As They Want To Be Done Unto"
Received on Sun Jun 13 1993 - 23:17:32 CEST