July 7, 2008 at 10:35 am
I am working with one of most poorly designed databases I have seen in my entire career (and I have seen quite a few). The database we are using is an unnormalized migration from an old FoxPro (dbase-like) database. It is replete with repeating groups, redundant data, incomplete or missing keys, and total lack of defined relationships (left to be done in the app code).
I looked at it as an opportunity to make some radical improvements. However, my management is resistant due to hundreds of application coding (FoxPro and VB.NET web pages), which would require massive changes (none of which use a OOP MVS design) and are adamant against (unproductive) changes (in the face of daily fire-fighting mode issues due to the poor design).
I am charged with converting much of the old FoxPro code to VB.net web-apps. I had wanted to create a whole new "normalized" database design to run concurrent with the old design, updating both at the same time, until all other programs could be converted to the new database. However, I was told we will tackle the database rewrite in the future and I should write all my applications to use the existing database "For Now!"
I believe this decision to be a fatal flaw, which will make a "future" database conversion even more unlikely, and one which extremely hampers my ability to deliver a solid performing web-based front-end. What I would like is some convincing arguments to make the database conversion a priority instead of a merely "nice to have" concern.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler
July 7, 2008 at 10:55 am
You are probably trying to argue at too detailed a level.
Management at most companies care about money and time. Ignore the "right way" argument completely and try to deal with it as a cost-benefit.
I have had to do what you are doing several times. Unfortunately for you, one of the by-products of doing the entire thing correctly is completely unacceptable. You will turn the conversion into a loger-term, single-deliverable project. In my experience, company management does not want to wait a year for a project to return any results and then get everything. The truth is - they are correct. Projects like that seem to rarely meet expectations, often run long and cost more than planned, and lots of them fail entirely.
You need to convince them that you can reduce costs with proper design. Up-front costs are typically higher, so you need to come up with a CBA that can show them that the software could be cheaper to maintain and easier to change with the proper modifications. This needs to show a return on investment within the time you capitalize your software and they will often start listening.
Then, you need to come up with a way to deliver that in pieces so the progress of the project can be monitored. If you can deliver several pieces in a short amount of time and without going off of your timeline or budget, they will probably let you continue.
Finally, if you do all of this and find that it is not cheaper to produce the superior product, admit they are correct and build the POS as planned. Sometimes building garbage really is the more profitable way to go - and at the end of the day that is what you want to give your company.
July 7, 2008 at 11:17 am
I tend to agree with Michael.
One thing I'd suggest is looking for a small piece of this to tackle, perhaps replacing some tables with views and building a better underlying structure. Or start replacing lots of queries with stored procedures.
The key is to do things in place, understanding that you can't break existing applications. And then really think about and document where this causes you issues and the actual costs involved.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
July 7, 2008 at 11:25 am
Like everyone else, I'd suggest starting small. The best way I found to convince someone of the need to normalize was to find data that was messed up and by being messed up would prevent the business users from seeing it. Misspelled words are the best. Find seventeen different spellings of New York (NY, N.Y.,N.Y,NY.,NewYork,New York, Nw Yrk... yeah, I had to deal with this one in the past) and then ask them how they're going to know where the money is going? It usually gets their attention very quick. But you can't try to redesign the entire database in one fell swoop. Start small. Put views up so that you can maintain backwards compatibility... it's hard work.
----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software
July 7, 2008 at 11:33 am
Also - work "inwards". It's often easiest to start on the "periphery" and work your way inwards. In other words, start with tables with the fewest relationships, and work up to the tables most interconnected.
It also never hurts to work on "what hurts the most". Find what is killing things, and fix them. Having some performance gains under your belt tends to help with getting more traction. Things like what Grant is getting at help a lot too, but they may not be the bad performers (meaning they're dumb but they're not dragging everything down....)
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
July 7, 2008 at 11:54 am
Michael Earl (7/7/2008)
. . . Sometimes building garbage really is the more profitable way to go - and at the end of the day that is what you want to give your company.
So I should want to give my company garbage? Because, that is what they will get in terms of performance!
I know how to start small and do it in increments, which was already in my (rejected) plan. Coming up with a CBA is best, but I suppose what I am asking for is concrete CBA type arguments to demonstrate the long term advantages over the constant problem "fire-fighting" mode of operation we currently have and elimination of all the "work-arounds" that in the end don't work and serve to further complicate the design.
Another of my problems is that there is no such thing as configuration management or documentation of any sort. Trying to provide any kind of decision analysis or design documentation gets zero results, as management and others are too busy fighting there daily fires to be able to read more than 20-word paragraph in an email, no matter how well structured the document maybe. -- I guess I am just venting my frustration and should go with flow until I find something better!
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler
July 7, 2008 at 12:10 pm
What I meant was that writing great code is sometimes not a profitable endeavor. Everything has to be balanced. Corporate IT often means you compromise making the assumption that you will have developers on hand to deal with changes and issues later. I think that approach sucks, but it sometimes ends up being more profitable than writing something that is perfect.
It is difficult to deal with companies that have dug themselves a big hole with this type of thinking though. The best you can do is show them the hard figures of what their current approach is actually costing. Good management will be happy to listen about ways to reduce overhead with some spending now. Even bad management will often listen to this type of argument. If you can actually report to them the costs of firefighting, they will often be receptive - so don't give up too quickly.
Just don't get frustrated and stand around saying that everything is wrong and it is costing more this way until you actually have real evidence to back you up. Even if you do manage to get someone to listen to you, if you just spout out "look at how awful this is" and don't actually have a CBA to back you up, you will quickly become the complainer that nobody wants to listen to.
July 7, 2008 at 12:30 pm
Ron Kunce (7/7/2008)
Michael Earl (7/7/2008)
. . . Sometimes building garbage really is the more profitable way to go - and at the end of the day that is what you want to give your company.So I should want to give my company garbage? Because, that is what they will get in terms of performance!
Never underestimate the power of garbage. I have seen some orgs turn garbage into a profit center. It's easy: gets customers on the hook, fast-talk your way through convincing them that said garbage is "perfectly acceptable with every other customer", and then CHARGE said customer an "upgrade fee" to fix said ugly code. Better yet, charge EVERY customer the full amount each and every time they discover the bug in their own installation.....
Sound familiar yet?
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
July 7, 2008 at 12:33 pm
My general approach when I face these decisions and discussions is the business level approach. Getting down into the nitty-gritty details of performance means very little to even a CTO/CIO unless they have a DB background and even then they are likely somewhat removed from the systems...as they should be.
Break it down to dollars and cents (Or sense sic). Show, at high level, reduced processing time - this equates to fewer servers as we grow, or data integrity - thus less reporting errors due to improper data manipulation, or perhaps ease of maintenance and development - thus fewer people required. Anything that relates back to the bottom line in a positive manner is something that provides it's own argument. At the end of the day they are concerned with business principles and not how many cxpacket waits are going to be saved.
July 7, 2008 at 12:49 pm
Here is a simple rule. Show that the change (hopefully little) that you are going to make can be equivalent to $$$ for the company and you will be on your way for bigger changes in the future 😉
* Noel
July 9, 2008 at 10:51 am
HI,
If you project your trhoughts in terms of money and flexibility to your management then they will agree. You need to tell them about long term benifit. Probably you can go with CASE study, take one functionality/Module and list out the demerits of it in current system and provide the benifts if we go with normalized DB and well structured VB.NET/FoxPro architecture.
This is how i did it for my project. I hope it will work for you too,
Thanks -- Vj
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply