Re: Multiple specification of constraints

From: Jerome H. Gitomer <jgitomer_at_erols.com>
Date: Mon, 08 Mar 2004 10:51:19 -0500
Message-ID: <404c966f$0$3099$61fed72c_at_news.rcn.com>


Dawn M. Wolthuis wrote:
> "Jerome H. Gitomer" <jgitomer_at_erols.com> wrote in message
> news:404a22a3$0$3084$61fed72c_at_news.rcn.com...
>

>>Dawn M. Wolthuis wrote:
>>
>>[Big Snip]

>
>
>>My model perpetuates the dba and developer project team for good
>>reason -- Separation of Authority.  It reflects the need for
>>commercial enterprises to protect their data from change except
>>through authorized, controlled and monitored processes.  Those
>>who control the data should not develop the procedures that
>>operate on the data and those that develop the procedures should
>>not be responsible for the integrity of the data.  Experience
>>has proven that it is too risky to do otherwise -- not from a
>>systems point of view, but from the point of view of the
>>enterprise that owns and uses the data.

>
>
> I think this is the best reason I can see for separating these roles. I
> don't think it is good enough in most cases, however, to put up with the
> side-effects such as:
>

        Stop and think carefully about what you just wrote. I don't think you would be happy if the IT departments of your bank, your credit card company, your mortgage lender, your automobile loan provider, and whoever you got your tuition loans from didn't have separation of duties and extensive checks and balances built into their systems.

        The best way to enforce the universal application of common constraints is to incorporate them into the database. This is because they then appear once and only once in the application and, hopefully, in the institution as a whole.

        Allowing individual developers to provide their own constraints (which implies duplication of constraints) will either have an exponential effect on the cost of maintaining the application or make it unmanagable.

> 1) code that has duplication of constraints (as is the topic here)

        If the constraints are in the database there is no reason for them to be coded in the application.

> 2) meetings and more meetings to have people attempt to agree when they have
> such different goals which is often the case when putting a dba and a
> programmer in the same room

        There is one and only one set of constraints that apply to data. It either meets the constraints and is therefore acceptable or it does not and is therefore unacceptable. There are no issues between the dbas and the developers in this regard.

> 3) high cost of ownership of software due to cost of maintenance including
> changes to "constraints" in multiple locations, multiple people & skillsets
> required to make changes, etc.

        The cost of software maintenance is negligible in comparison to the cost and damage resulting from the failue to catch an error in, to stick with the financial industry, the savings account processing or loan processing applications in a bank.

> 4) and a few others, but I'm boring myself (sorry, I'm guessing you're bored
> then too).
>
> When the issue is whether to drop a bomb somewhere, then I want checks and
> balances. When it has to do with painting a wall in my house, I really
> don't want the speed & quality of committee work on that effort. I guess
> I'm saying that the risks that the average company with the average
> information system has to accept in not separating these two roles is worth
> it in most cases. --dawn
>
>

        In closing I will cite one actual case of a bad program constraint that cost millions of dollars. The company in question had many divisions, including a computer division. A new director in looking over the division balance sheets saw that the computer division was losing money and forced the sale of the computer division. When the profits did not increase to the expected level in the following year an investigation revealed that the revenues for computer service had been credited to the service division rather than the computer division and that the computer division really was profitable.

        The code constraints in the program used to determine which division received credit for revenue were incorrect. Unfortunately they were buried too deep in the system to have been discovered in time to avoid what proved to be a very costly mistake.

Jerry Received on Mon Mar 08 2004 - 16:51:19 CET

Original text of this message