Editorials

How Do You Choose Your (Database) Weapons?

There are a huge number of different alternatives when it comes to platforms and tools that you have available to you when laying out your systems. How are YOU choosing?

I ask after reading Craig Mullins post to TechTarget, talking about all of the different tools and choices you have when it comes to operational database systems. This was, frankly, a new term to me – so I dug into his post to see what’s up.

There are some really great points in the article, and I couldn’t help wondering at the array of options we collectively have. From on-premise to cloud to everything in between. I also couldn’t help wondering if things have changed. Traditionally, at least in my experience, moving to or adding a new database environment to an existing infrastructure is a complicated and challenging task.

Usually when I was working with a given solution, the hesitation and downright stubbornness to consider new tech was a genuine issue. It was really difficult to convince the powers that be that the new technology and the associated learning curve and added support costs and risks were outweighed by the functionality of the tool.

That is to say that the information tool brought more to the problem in terms of solution than it brought in terms of cost or risk.

It’s a very difficult thing to prove or convince others of when looking at tools.

Do you see this too? How do you work with those making the choice to show them the different options? Even in your own decision matrix, there simply must be “costs” (whether actual or intellectual) associated with introducing and depending on a new platform. How to do you evaluate those and decide whether it’s the right choice for you?

In some cases, it comes down to spreadsheets. I’ve been in situations where we needed to literally cost justify the idea and choice. Support costs, development costs, transition costs and all of those – they all come into play. Frankly, if I was in a management role position in the decision, I’d add a “slush” factor – a factor that multiplied the projected costs by a factor that I felt spoke to the unknowns.

I usually added at least 50%. Sometimes more depending on who was presenting.

That’s not a lack of confidence, it’s just a lack of cohesive knowledge about what it really takes to put a new platform into the mix.

Interestingly, there were still cases where new tools and technologies made sense. So it’s not like there can’t be huge benefits, it’s just that the effort to implement them has to be carefully considered.

How do you evaluate these other technologies? How do you decide to move ahead, to drop or even consider in the first place, a new platform?

Facebooktwittergoogle_plusredditpinterestlinkedinmail
  • AZJim

    Ah, the old question of tools. Let’s see, I remember this same controversy as a junior DBA in the 1980s working on mainframes. We had the super techies and we had the management presenters. The super techies could tune better but could not cost-justify a solution with their tool because managers would glaze over with too much detail. Then there was a tools that presented a simple graphical solution. We ended up first purchasing the “simple” tool (they were both about the same cost) because managers understood what the presenter was saying.

    Fast forward to my last company where we were troubleshooting Unix and mainframe databases, “simple” again beats the complex. But this time it was the techies (me) that wanted the highly graphical, intuitive tool. I was responsible for mainframe, Unix, and SQL Server databases and didn’t have the luxury of doing a deep dive into the internals (too much diversity). And if the tool had the same GUI on Unix and Windows, that was the gold standard.

    If you are buying on price alone, be prepared to have struggles — especially if you have SQL Server and Oracle to support. I suppose that it comes down to how much rapport the IT department has with the business. If the business respects IT, they should be able to get the tool they need.