In most cases, this decision will be easy for you. Surely creating your own database is better than what you're starting with, right? In the vast majority of cases, probably very true. But there are some very good reasons to contemplate other solutions. A few things to consider below:
1. What will the database be used for?
If you're thinking of creating your own database to store orders, key customer information, or any other sort of "transactional" or business-critical information, think about it carefully. Now this will largely depend on the size of your organization, but if you have any sort of development or IT resources, or adequate money, consider leveraging your development staff to create the solution you need, or buy one off the shelf. If you work in a small company, creating your own database is probably the best, and appropriate, option you have. If your database is going to be used to store data for what I'll call "secondary use," like analysis or data crunching, creating your own solution is a great way to go. You don't need to worry about multiple simultaneous users, audit trails, etc.
2. Who will be using it?
I'm reminded of a project I undertook years ago when I was in sales. Our customer relationship management (CRM) implementation was a disaster, and my VP wanted something that our group of eight customer-facing staff could use to track activities and opportunities. Simple enough, I had created plenty of databases at that point. I failed to realize just how slow a desktop database application like Access performs when it's sitting on a shared file server. When more than one user was in it, it was abysmal. My point is this, if it's just you and a few others working in the database infrequently, Access is a good choice. If it's you and ten+ colleagues looking to maintain important information on a daily basis, you're probably better suited for a more robust solution. That might come in the form of purchased software, your own development group creating a more scalable application, or putting in a SQL Server or MySQL database with an Access front-end.
3. Where do you want to go?
After years commuting sixty miles, I took a job with one of the largest software companies in the world, much closer to home. One of the things we tell customers when they are evaluating our software versus their own in-house solution is this...do you want to continue focusing your energy and time developing software that is already available and evolving over time? To be clear, this blog has nothing to do with my primary employer or what they sell, but I'll pepper my comments with experience from there. My point is this, if what you're doing is considered to be fairly "mainstream" in terms of enterprise software, it's important to think about whether ten hours here and ten hours there may add up to a whole lot of time just to create something that already exists (time-value of money). In many cases, you're probably creating something very specialized for your business needs that just doesn't exist in any pre-packaged software. But be sure to do the research. If something already exists, is it light-years ahead of what you're doing and in your budget ballpark? You'd be amazed at what is out there. If something does exist, but it's out of your price point or doesn't quite fit your needs, D-I-Y on with confidence.
4. Will it get you praise
If you happen to report to someone (i.e., you're not your own boss), test the waters with what you're planning to do. In most cases, you're no where near a software developer much less in a development/IT role. So if your manager isn't keen on you becoming one on the side, find out early. You may be able to bring them around ("we can save X hours a week if you let me"), or get them on your side to push for the "right" people to do it. Either way, taking on projects like this can get your promoted, or stall your career if your management thinks you're not focusing on what's really important.
No comments:
Post a Comment