Re: Multiple specification of constraints
Date: Mon, 8 Mar 2004 12:31:43 -0600
Message-ID: <c2ie6m$pu5$1_at_news.netins.net>
"Jerome H. Gitomer" <jgitomer_at_erols.com> wrote in message
news: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.
"Extensive checks and balances" is not the same as "separation of duties" but even with a separation of duties, separating them so as to get multiple sets of constraint logic does not make good sense.
> 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.
If one could incorporate all such constraints into the database and use them for all needed purposes from there, that's fine. But you can't, so they end up strewn throughout the code. Do you read code often? Are you not seeing any additional constraint logic for validation, GUI display or other purposes within the code? If not, I suspect your setup is exceptional.
> 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.
No disagreement here -- that's was my point up front, but from the other direction. I simply don't want to have the constraints spec'd, respec'd and then spec'd some more as seems the case in code I have seen over the past couple of decades.
> > 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.
Perhaps you have missed my argument on this. Many, many constraints show up in the software applications. For example, if the database says that a particular attribute must be validated against a table of possible values, then that constraint is applied by the database when CRUD services are invoked. However, prior to then, a GUI is likely to toss up a drop down list of valid values for data entry so that no values other than the ones the database constraint permits are available to the user. The user never enters an invalid value in this application, then, but the application developer invariably as recoded the constraint that says that this field is validated by that table.
If this is not the case in your situation, how is code that displays the GUI getting such information? Is the software developer really reading this constraint info from the database? Even if they were to retrieve a spec from the database, they would then be reimplementing the logic that interprets and applies that spec unless the database validation logic is able to be invoked for purposes other than CRUD services.
> > 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.
Is that the experience of others on ths list too? I work with small to mid-size businesses. I don't see blatant issues between the two groups -- just a bit of passive-agressive behavior. DBAs build walls and programmers build ladders.
> > 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.
I certainly believe that good QA is important, I just don't see the current split between the roles of the DBA and programmer as contributing to that quality in a significant way. I do see where it could make it a little more complex for a corrupt developer to steal, but if the production environment is adequately locked down ... Anyway, as I mentioned, the issue of having multiple people with multiple roles so there are checks and balances is the only reason I can see for the currrent strategy of separation of skills and roles between dba and programmer. So, that type of security is still needed, but it doesn't have to require that there be two such groups, nor that they use two entirely different toolsets for constraint logic (for example).
> > 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.
Good story. We, as a profession, seem to have a poor handle on "our own" data that we use (programs, database-spec'd constraints, etc). It is not surprising that this data was "buried too deep".
Cheers! --dawn Received on Mon Mar 08 2004 - 19:31:43 CET