Re: State of IT and DBMS expertise

"Frank Hamersley" <FrankHamersley_at_hotmail.com> wrote in message news:7%Jjd.27497$K7.17991_at_news-server.bigpond.net.au...
> "Laconic2" wrote

> I can think of another reason for durability - a propensity on non-related
> parties to avoid these apps with 10' barge poles hence they live on beyond
> their natural term (i.e. on life support perhaps). The only serious
attempt
> I have observed* of this class was a treasury accounting system that
> couldn't reliably compute simple interest on an "At Call Account".
>
> I know it didn't survive (even though significant resources had been
> consumed) in its treasury role because I was the project manager of the
> successful RDMS based replacement. Parts of the Pick stuff lived on -
> mostly as a glorified reporting engine.

I had a similar experience, replacing a FOCUS hierarchical database that was being used primarily for reporting.It only took a few weeks to design and build an Oracle based solution that was more flexible, more powerful, more programmable, etc. And in took less than one week to build an adequate ETL program to get the data from the original sources, and keep the Oracle database up to date. This doesn't necessarily mean that Oracle is a great tool. It just means that the project is eminently doable, and by one person.

OK, OK, I didn't work in a vacuum. If the network was down, I called the network people. If my desktop failed, I called the desktop people. But the DB team was one person, and then later three people.

 The FOCUS part of the app lived on, mostly as a glorified reporting engine. And, by the way, there's nothing worng with glorified reporting engines. They serve a useful function. They just aren't databases.

> From my perspective it was clear
> the IT amateurs involved didn't have the rigour that this particular
> business demands and having a warm and fuzzy environment did nothing to
> improve that situation.

IT amateurs can, on occasion be brilliant at analysis. They usually fall down on design and implementation. IT professionals on the other hand, are very strong at implementation, and sometimes design as well. But we usually can't wait to get started on the "real project", so we settle for a half assed analysis, hoping that the details will emerge in the course of the project. Sometimes we're lucky. Sometimes we're not.

The point is that Subject matter experts and IT professionals should learn how to work together, rather than as competing camps.

> There may be other areas of business where rigour
> is less a contributor but I am not in that space (nor likely to be
either).
>
> In truth, a similar malaise (low attention to detail) IMO is often found
in
> all areas of IT (MS being a prime example) and I feel this has a greater
> impact on the outcome than the choice of tools.

Agreed. Received on Mon Nov 08 2004 - 14:25:42 CET