November 21, 2007 at 11:28 am
This is a question I was being asked during an interview a couple years ago. I think it is a pretty good open question. I keep it in my mind whenever I need to evaluate tools for database administration.
I post this question here. Let’s see how many thoughts we can come up with, and what good/bad experience we can share.
November 21, 2007 at 12:22 pm
Ideally when I'm looking for a new tool or tools there is a goal that I'm looking to accomplish. So I think the first step is to define what that goal is and define exactly what you are looking for from a tool. Then research the available tools on the market that accomplish that specific goal and do a cost/benefit analysis of how much the tools costs vs roll your own and define where your ROI is and whatnot.
November 21, 2007 at 4:52 pm
Vivien Xing (11/21/2007)
This is a question I was being asked during an interview a couple years ago. I think it is a pretty good open question. I keep it in my mind whenever I need to evaluate tools for database administration.I post this question here. Let’s see how many thoughts we can come up with, and what good/bad experience we can share.
It's simple... no different than a very long winded interview... check the documentation, ask some questions, run them through a test, find out how much they want, check their background/referrals, etc, etc.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 26, 2007 at 8:10 am
Evaluate?
Use it to solve a problem and either decide how well it works relative to how much time you spend. What tool works for you might not work for me.
It's one of the reasons I don't like to review tools. I use them (often) in a very narrow fashion. And I think people might give more weight to my opinion that it should have. I don't necessarily think a bad review from my perspective means it's a bad tool.
November 26, 2007 at 10:51 am
Maybe I should put the question this way.
What are the considerations when evaluating/deploying a database administration tool in your enterprise environment?
My thoughts are:
1.research the market
2.read document
3.trail version
4.contact vendor for demo with questions
As for questions, I have the following:
Deployment requirement comply with your architecture and Standards/policy; client side tool or server side tool/performance impact/port to open/database size or space if needed/security credential needed/vendor support accountability
5.test on your own environment (very important, you may hit the bug)
6.license/ROI (Thanks Luke)
7.check version/upgrade
8.join vendor’s user group
9.ask SSC for input (as we are here)
anything else?
November 26, 2007 at 11:07 am
I am actually interested in hearing if there are some systematic approaches to this as well. I am on the Jr. end of the spectrum and just tried my first eval. I spotted 2 things that I did wrong in the eval period. One of the first things that I did was download the trial version. I did spend SOME time on the documentation, but there are 2 things that I did not do. First, I should have had a demo from the vendor. That would have saved me a lot of time and frustration. While the tool was reasonably intuitive, I am sure that I would have benefited from seeing someone familiar with it using it. Second - I should have clearly defined where I would use and what I thought I was going to do with the tool and then work it into my schedule for a period of time. That would have given me a much better picture of the ROI. I tended to 'play' with the tool and if I was crunched for time - I just went back to the 'old way'. Eventually, my trial ran out and I am sure that I did not really give the tool a fair shake.
- J.
November 26, 2007 at 11:22 am
I think Steve hit the nail on the head and stated it a bit better than I did in my first post. Figure out what you're going to use your new tool for. Is there a problem with the existing tools? Can you do something faster, better, with more accurate results from your new tool? The biggest challenge in an Enterprise scenario is that the tool I prefer and know might be better to me than the tool you choose. Granted supporting both may be a cost and/or inconvenience that the enterprise does not want to incur, but sometimes it's better to spend a few extra dollars to keep your people happy than to take something away from them and give them something new that "is better" without giving them the chance to see, touch and feel a tool to see why it's better. If it saves the company a couple of hundred bucks but the interface is so horrid(or different) that it makes it more confusing to work with, it would be hard to sell me on how it's better other than it costs less.
Then of course you can get into discussions of hard costs vs. soft costs and it can get rather complicated rather quickly. In then end it comes down to identify a problem, find a solution that works in your environment and then look at other alternatives to make sure you get the biggest bang for you buck.
November 26, 2007 at 11:24 am
also as to time limited eval periods... typically if you like a tool and think it might be something you want to pursue, most vendors will be more than happy to extend your eval period if they think a sale is imminent.
November 27, 2007 at 4:58 am
I don't know about demos. Some are good, some are bad. But most of them are canned. Which means the demonstrator is going to show you all the scenarios that he can think about (and of course all his data will be scrubbed so nothing fails).
A demo never gives me a true feel for whether or not the tool actually works with *my* database. And I know my database has problems. Since I can't see the demo guy's schema, I can't know that the tool will work with my schema. And if I find out that I need to take my database data and send it to someone else's database in order to use the tool, I usually mark that tool off my list of tools I want to use. I've already got a DB. Why should I have to scrub and reformat things to work with someone else's db?
Anyway, a trial version usually gives me a better feel for how much work I'll have to do to make the tool operate correctly with my data. Not to mention whether the tool actually does anything different from the home-grown MS tools. Most of the time, these things are built off items already part of the SQL Server Suite but made to look prettier. Note: I'm specifically thinking Dashboards and other BI tools with this conversation.
Anyway, my eval process follows a lot of what Steve has already posted, but primarily, I avoid demos as a decision making tool. The guy just wants to sell me something and will say whatever it takes to get my money, whether or not it's true... Oy, can you tell I came from a retail background? @=)
November 29, 2007 at 10:59 am
Personally, I don't really like 3rd party addons too much. The only ones I have used a lot is LiteSpeed and SQLCompare.
I've never been too interested in all of the dashboard type monitoring software for SQL Server. We had it in a previous company, but it was more of a visual for the rest of the support team to monitor when I was not in the office. I suppose that grew from reading forum posts on here - I'd find bits of advice on how to monitor aspects of SQL Server and I'd automate the process.
I did post on here a while back about 3rd party tools for replication - but only because I was asked to do so.
But anyway, I digress...I guess you need to get 2 or 3 different vendors in and speak with them in detail about what you expect to see from their tool and what they can provide for you. Thats the real starting place and following on from that you'll need the demo software (hopefully fully functional) and test it like crazy. It's not a process which you can rush through. Tools these days can cost a lot of money, so you need to invest your time to ensure you get the right product.
November 29, 2007 at 11:46 am
Heh... I'm a bit more like Clive... write my own tools whenever possible... that way, they do exactly what I want and I can change them if I need to.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply