Building a Demo Server
-
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sjones/buildingademoserver.asp
-
Good article. Makes sense, but not sure I agree with the demo server if you can run it on the production server. Running on last years hardware is bad, but so would running on a separate box with no load, then they see slower perf than the demo - thats bad too.
Our issue has always been data, if you have one demo db it tends to get junked up.
Andy
-
I've often had semi stable code with new products being released and the collisions between the production server and demo server weren't worth it.
Having a decent demo server has always been pretty important and I've usually been able to scrape together enough parts to beef it up. I'd be wary of production just because of the possible problems with reconciling data as well. Keeping demo transactions out of the accounting system gets to be a pain.
Steve Jones
-
Steve I agree with the information in your article for the most part. I believe that this is as it should be but I disagree with no load on the hardware when a demo is running I believe that clients need to see the real thing. Does this mean dumpy hardware, no. What this meands to me is definately not in a production environment but a seperate environment where multiple demos can be run at once. Do I need new hardware I do not think so but then again I am not goingto run a dual 450 PII server with a crapy raid controller either.
For this kind of project I call a vendor that deals in reconditioned hardware and for the price of a New PE2650 (2way box) I get a PE6400 (4way box) older processors but descent power and more importantly a 4way box. If a web app is the front end then I use an IIS box as the front end for ease of administration on pretty much any old config. If it can handle 30 users I think that I am good (most of the time). Most importantly for any project I think scalability and think that it needs to be (as you clearly stated) treated just like production. If i have reporting features running on one or more boxes and transactions processing on others then I want it to look like this if I can get management to buy off on it. If not as is the case a lot of the times I may run seperate instances on the same machine so I can at least act as if I am emulating as close to the same process as I can. Thanks for the article and this site it is one of my favorites and I am thinking about writing some columns as well.
Scott Dexter
DBA/Consultant
DEX
😀
The more you help the business, the more they will help you...well sometimes anyway. -
Good suggestions. I've got a couple more coming in Part 3.
Steve Jones
-
Excellent I look forward to reading it.
Scott Dexter
DBA/Consultant
DEX
😀
The more you help the business, the more they will help you...well sometimes anyway. -
Steve,
Thank you for covering this important part of a products lifespan. I would like to recommend that the demo data that the system is running, is as close as possible to a very recent total copy of the live data.
This will give the prospect a realistic view of the performance, and he'll be impressed when he finds out that the demo is not done on some Mickey Mouse data. Users like to see dates and rates that are current, not something as of last year.
Regards
Henrik Staun Poulsen
Stovi Software, Denmark
-
Good article Steve, this is an area that is too often overlooked. Just a few thoughts on the data side : My personal preference for demo data is to use a backup of production data and restore it onto the demo server, although this obviously does create issues with any personal data, which needs to be changed if it's going to be demo'd to clients. An advantage of using 'live' data is that you avoid the temptation of rookie developers to put in nonsense names. I once saw an extremely uncomplementary reference to a Mr Bin Laden, along with some personal, antagonistic comments appear courtesy of a very immature developer on a demo server being used at a customer site, not too long after 9/11. Suffice to say he got a good dressing down from the MD and was lucky not to loose his job. Not saying you won't get anything offensive in production data, but using developer's test data is never a good idea unless you have time to pre-vet it.
All sorts of nonsense creeps in.
With regard to separate boxes, I think you have to consider your target audience. Whilst I like the ethics of giving the customer a 'real' demo on the same box as a production system so that they know how it's going to feel in use when they've bought the software, I think this is fine if you are dealing solely with a technical audience who understand that occasionally you get locks, have backups going on in the background and have business users running hour-long reports.
Throw in a non-technical manager who's going to get inattentive at the first mention of anything remotely complex, and I think you have to consider a separate system. These are the sort of people who will get bored waiting more than a couple of seconds to see what they want, and will not be able to appreciate the technical reasons behind why the system is occasionally slow. Nor will they want to know. Unfortunately they are invariably also the ones holding the purse strings, so if you're up against competition in a tender, I think you have to consider the technical ethics against the risk of losing business to the competition because they've put their demo on a fast, non-shared machine. I don't like it, but at the end of the day, making the sale pays your wages, so you have to ensure that demo's going to be as impressive as possible.
If I was selling my car, I'd give it a good once-over to make it look its best. I know it's going to get dirty in practice, but if it's clean when it's seen it's more likely to sell. IMHO.
Jon -
The most important part of ANY system is the data, and to a customer the most important data is THEIR data.
When I was showing geodemographic marketing systems we would deliberately populate the system with the customer's own data so the customer could relate to what they had been shown.
The brighter customers will use your system to validate a fact that they already know about their data.
A good sales pitch should be tailored to the customer. You should research your customer to the point where you can predict 90% of the questions they are likely to ask. In effect you "storyboard" the sales pitch.
Now I am working for a web development company using a number of CMS's we do demo's on high spec laptops with Windows 2000 Server installed. In our case the fact that the system can run on perceived low power machinery is a plus because the IT types will see that they can use the system for development on the crap that their finance department expects them to perform miracles with.
Anyone who is not an IT guy thinks "Wow, look at my data"! They will also have the attitude (unless your system really is a dog) that performance is an IT problem and that they are just interested in the functionality.
It is implicit that the live system won't be running on a laptop so part of the preparation for the demo is making damn sure that the demo is slick, works fast and well!
If you want to be honest about the performance of your system then publish benchmarks and ask former customers to act as references.
DO NOT do a demo where you imply "here is an example of our system crawling/crashing/trashing everything else on the server". Your potential customer will remember the fact that it crawled/crashed/trashed everything else on the server and not the why's and wherefores.
Don't get me wrong. Be honest but not too honest. Accentuate the positive.
-
Accentuate the positive - thank you, that's the phrase I was looking for - so true. Loading up the customer's own data is a definite bonus, although in some situations it can be a luxury you don't have time to prepare for. I guess it depends on the lead time for the sale, when the competition's getting their demo in, how much resource you can throw at the data load, and how long it will take to perform. Also depends if the customer's got anyone they can free up to provide the data to you for the load - it can be a dual edged sword if they see it as a burden when they don't know if they're going to buy your system yet. But I'd definitely use it as a deal-clincher if they're interested after the initial demo.
Another feature of a demo server that's useful to have is a virtual machine running on it. I would highly recommend buying the software for one of these. VMWare's my favourite (http://www.vmware.com) but there's a few offerings out there. Nice thing about these is that you can have a clean copy of the demo machine in its original state, ready to go for the next demo, without doing an entire machine re-build. Saves hours of effort and worth every penny. Especially useful if you're visiting one customer in the morning and one in the afternoon, it's so quick to revert to a known system that's in a reliable state, that you can depend on. There's nothing worse than having a developer muttering about registry settings in front of a potential client whilst everyone waits around the table for the system to be fixed. Or worse still having them see the previous customer's data still in the database - theirs might still be in there for tomorrow's demo...not good.
Using a high-spec laptop is a great idea, much quicker than lugging a monitor, server and cables up stairs and lifts/elevators. It also lets you set it up for the next customer whilst someone else is driving, or whilst you're on the train, maximises use of what might otherwise be dead time between demos and reduces the irritation to the customer whilst the demo's being set up.
Jon -
I've actually used VMWare as well (http://www.sqlservercentral.com/columnists/sjones/buildingademosystempart3.asp) and it is great. I've got a better solution than that for high end corporations, and one that works extremely well.
Using customer's data is extremely helpful if you can get it. And something you should shoot for if you've got that luxury, but I've worked in some environments where the volume is too high to load things up.
-
I've had the "too much data" things as well.
Because the sales activity was regarded as so important we developed special scripts that produced a specific sales version of the database.
A good salesperson can steer a customer where they want the customer to go whilst giving the illusion of allowing free choice.
The lap-top route has a number of advantages.
- You prepare the customer psychologically for reduced data.
- You have a portable system.
- The salesperson would sell the customer the idea that the reduced dataset was due to the high regard that your company places on its client confidentiality.
- Your customer is working in isolation so
- It doesn't matter if they cock up your system.
- Their activity won't impact anyone else.
- You control what they can see.
- If you have a lap top with a removeable hard drive then you can install a copy on each hard drive so you don't have a lengthy reload after each demo. You can wait till you get back to base and refresh the lot en-masse (or delegate it)!
At the end of the day I'd say that there are two main factors
- The quality of the salesperson.
- The identification of the decision maker and/or influencer within the customer group and targetting your sales pitch at those people.
Its sad, but true that the IT guy won't necessarily feature very highly in the decision maker/influencer stakes even if he is invited to the meeting!
Colin Chapman (founder of Lotus Cars) once said, any fool can make a bridge that stands, the genius makes a bridge that just stands.
An IT guy will try and show the customer that works, a salesperson will show the customer a system that just works.
-
there are some excellent posts here!
recently in the last 9 months I had to setup a demo machine, (not exactly a DBA job, but as the bulk of the work was installing Windows Server on VM's along with SQL and various office products, depending on what each client was running at their base.
In order to maxmize impact the sale-force decided it would be ideal to mimick (as closely as possible) the clients environment on a laptop, including installed (standard) software, such a Office 6 thru 2000, SQL server 6.5 thru 2000 and various other tools.
Each client had their own virtual machine, their own login and hteir own sample data (which of course may have been anonymized at source) but the end clients user experience was obviously very positive, the environment looked as if it were the same from the client-site, response would were much quicker as the demo-machine was optimized for each client.
of course one thing to remember if you take the virtual machine route is to allow a little extra juice for the overhead of running a VM.
-- Alex
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply