Re: Just one more anecdote

Bill H wrote:
> Dawn:
>
> I'm thinking it's not just the dbms.

I agree that it is not just the dbms.

> The hypothesis that the complex,
> tiered, development model is the culprit here is an excellent fit for the
> facts in this case. In addition, it is an excellent predictor of future
> complex, tiered, development projects in the future.

I'll definitely grant that in a move from single-vendor all-in-one development and run-time environments of the 70's & 80's (like console stereos) to multi-vendor, distributed environments, there is definitely added complexity no matter what tools are used.

There are trade-offs with each choice, such as a choice between procedural and OO languages, between virtual machines or multiple OS's, between http and other protocols, among various security strategies, among dbms's, etc. Some of these will make a big difference in the cost of ownership for the resulting software applications, while others will not.

Data modeling might not be the biggest issue, but it is one where I think we often did a better job when working with our "consoles," and because data modeling is so integral to s/w development, I'd like to see if such a approach could also be used today. When relational theory came on the scene, we started modeling data according to set theory. I thought it sounded so much better to base a model on mathematics than doing the ad hoc thing, but in practice, I'm not seeing the benefits of using SQL-DBMS products. Before that time we modeled data according to what? According to what seemed like a good idea? According to experiencre? Maybe we were just wrong, but maybe when we dumped the old approach for relational modeling we tossed out too much of the common sense we had been using.

> A RDBMS has its limitations but I don't think it's fatal.

I agree it is definitely possible to have a successful software application using a SQL-DBMS. I'm concerned about the cost of ownership, however.

> True, one of the
> more flexible DBMS models will make the development less costly (easier) and
> thus more successful, but not for the suspected reasons. I believe the
> reason is because the flexible DBMS models incorporate tiers and simplify
> the development process.

That is the "console" theory that I have heard expressed here before. That might be the whole of it, in which case taking pieces of it into a distributed, multi-vendor approach won't help. I don't think that is the whole of it, however, but I don't know how to find out.

> A person who is completely familiar with payroll will develop a far more
> stable, flexible, and cost effective payroll package given the appropriate
> tools than a technologist who can manipulate tools that have no relationship
> to the payroll development environment.

I agree, but I'll also say that a person completely familiar with payroll who is paired with someone completely familiar with software development is more likely to produce a highly maintainable solution. But the more flexible the tools & s/w dev environment are, the more successful the payroll expert can be developing a system even if not a s/w expert. The data modeling approach and the data model are both part of the flexibility of a system.

> The flexible DBMS models contain a
> large amount of development tools and simplicity into their model.

I should have read a little further -- yes, agreed.

> Developing a computing solution is really a 95% solution...each component
> performs optimally 95% of the time. The more components used to build a
> solution the less stable it becomes. The R&R software writeoff is a prime
> example of this business and computing dilema.

One of my favorite quotations is from Toffler's Future Shock, 1970 "Each new machine or technique, in a sense, changes all existing machines and techniques, by permitting us to put them together into new combinations. The number of possible combinations rises exponentially as the number of new machines or techniques rises arithmetically. Indeed, each new combination may, itself, be regarded as a new super-machine."

There are reasons to complicate the landscape with new techniques and machines in the mix, but, yes, that can definitely explode the complexity. I do not discount what might be your hypothesis -- that it is this added complexity alone that accounts for the change in the cost of ownership of software between the console style and the distributed, multi-vendor environments. I'm not convinced that is the whole of it (at least I'm not YET convinced of that).

> It is a far better thing to consolidate development environments to make
> them manageable, and useful, to business people familiar with business
> problems than to break the development process into multiple tiers and
> components so the development process becomes a nightmare of competing skill
> sets,

Today, however, a completely integrated development and run-time environment, start to finish, front to back, is unlikely to meet user requirements. Do you have a completely integrated approach that does everything you need?

> DBMS components that need specialty administrators, set theory
> extrapolation, network specialists that can barely keep the computing
> environment communicating, etc, etc, etc. :-)

Yup. Each layer needs security, scalability, solid apis, excellent performance, etc. Cheers! --dawn

> Bill
>
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> news:1122344688.525517.39350_at_f14g2000cwb.googlegroups.com...
> > I'm sure there are numerous factors playing into the fact that the
> > system touted in this MS Word document
> > http://www.microsoft.com/resources/casestudies/ShowFile.asp?FileResourceID=1611
> >
> > has been discontinued and written off to the tune of $67 million in s/w
> > development as seen at
> > http://biz.yahoo.com/prnews/050721/clth018.html?.v=16
> >
> > This is yet another instance where a legacy system written with a PICK
> > (in this case), MUMPS, IMS, or other pre-relational database product
> > didn't successfully make the jump to a SQL-RDBMS.
> >
> > It is very likely that the conceptual data model and surely the
> > subsequent logical data model from which the original system was
> > developed would not play to the strengths of the SQL-DBMS. As much as
> > we might want to think otherwise, even the design of a conceptual data
> > model is influenced by the designer's knowledge of the target dbms. A
> > redesign of the data model for a SQL-DBMS is likely to both bump
> > features and increase complexity -- a harsh one-two punch.
> >
> > My conjecture is that downgrading, I mean moving, from a graph data
> > model to a relational data model and from a PICK dbms to the SQL-DBMS
> > were significant factors in this project failure. I could be wrong, of
> > course.
> >
> > smiles. --dawn
> >
Received on Mon Aug 15 2005 - 01:28:42 CEST