Your opinion is needed regarding a software system development
priority

An organization has purchased a COTS (customizable off the shelf)
software product for its Mission critical system. This is a multi
million dollar project. The committee that is overseeing the
implementation of the system was given the following choice.

A) The project could implement 100% of the data elements for initial
implementation, but not build any canned reports, OR

B) The project could implement 60% of the data elements and build 50
canned reports, which would be available for initial implementation.

There will be 15 legacy systems integrated into the new system.
Unfortunately, at this point I do not know the number, nature or scope
of the data elements in question.

I will accept in advance the following disclaimer from all that are so
kind to give their opinion: It is difficult to give an informed
decision without further knowledge.

Please state which option (A or B) you would choose and give a brief
or not so brief explanation.

Any and all opinions and experiences welcome.

Optional:
Also include your background, qualifications and years of experience.

Thanks.

This particular choice seems contrived. Is it an essay question for a
homework assignment?

IMO - it's all about the data. If your database is incomplete, what good are the reports?
Go with option A, then hire me to write the missing reports...

--
Paul Horan (building quality software since 1984)
Sr. Architect
VCI Springfield, MA
www.vcisolutions.com


"Pat" <sbcs (AT) sprint (DOT) ca> wrote

On Wed, 21 Jul 2004 14:45:22 -0400, "-P-"
<ent_must_die (AT) hotmail (DOT) DOTcom> wrote:


And then hire me to provide the missing 40% of the data.

Lemming (bottom-posting since 1533)
--
Curiosity *may* have killed Schrodinger's cat.

Bruce Lewis <brlspam (AT) yahoo (DOT) com> wrote

This is a real world situation!

Please give your opinion it's important.

Pat wrote:

Pat,

You're between a rock and a hard place, it seems.

Maybe this message won't have any answers, but it
may have questions which you should be asking either
yourself or your management to come to some
conclusion.

Strictly from a database point of view, I would want to implement
the database schema first but this may not be practical.
The reason being that the end-users will probably *not*
consider it usable without *some* reports. You wind up
having to balance the theoretical and the practical.

In my experience enterprises embark upon this kind of an effort
just because multiple (legacy) systems have different notions regarding the
same data elements. Keeping the data synchronized
between systems is both a monumental pain and
the cause of much consternation because System A
says "this" and System B says "that" and how do you
really know which one is right? If I'm correct in this
assumption, the end-goal is an "enterprise-wide data repository."
This starts with an enterprise-wide data schema, IMO.
(But that's my theoretical side talking.)

Having said that ...

Integrating 15 legacy systems is not a trivial task. There is
likely (likely? hell, there's a certainty) that there will be
data duplication between them and just identifying these instances
will be non-trivial (same data item, different name is a trivial
example). The actual reconciliation process
between data from Systems A, B, C and E may require
some very complicated logistics (creating snapshots, writing the necessary
code to cross-audit the data, worrying about how to handle
updates which may have happened to A, B, C and E while the
cross-audits were running, etc.). This is a time-consuming
and tedious process and I presume this is part of what you meant
when you said "implement 100% of the data elements."

(I may be preaching to the choir here, but it's always worth
mentioning, just in case.)

On the other hand, what good is a database if you can't get
data out of it? (The "canned reports" people are used to from
the legacy systems. You will find, if you have not already done
so, that people will complain if it's not in *exactly* the format
they're used to. People are this way.) So, my practical side
says that just doing the data migration without providing
these reports is not a viable option. (And if you even think
of letting the random users write ad-hoc queries on what I presume
is a substantial database, go lie down until the feeling goes
away!

Doing only a partial reconcilation has both risks and future costs.
By "partial reconciliation" I mean something like integrating only
10 of the legacy systems (about 60%), and leaving the rest for later.
Thus, systems K, L, M, N and O will not be "integrated" and
will continue to have inconsistent data for a time. Can you choose the
right subset of legacy systems to integrate so that you solve 80% of
the integration problems while still providing the canned reports?
(Note: 80% of life follows the 80/20 rule.)

Once this "10-fold" database is running (in production),
how difficult will it be to merge data from system K? System L?
Will it even be possible?

Will the canned reports have to be changed once the data from
K and L is integrated into the master DBMS? That's a cost.
Can you somehow create the schema such that there are empty
tables with K and L's unique data so that they don't? (This
implies knowing what the schema will look like at the end, but
just not populating some of the tables. Can you do that?)

After having said all that, my recommendation would be
to define the "grand-schema" (your ultimate goal), then
determine what the primary and secondary data sources
are for any given data element, and lay out a migration
plan with the sources in priority order (however you
define priority) and produce the "canned reports"
for the system(s) being replaced.

As I said, there are more questions in this message than answers,
but you asked for opinions.

NPL

Background: 3 days older than dirt.

Experience: All the way back to the days of "IMS as gawd",
up through the CODASYL wars and the "Relational Revolution"
and onto the OO stuff.
Had to design the migration of several legacy systems
to a centralized data concept (they went kicking and screaming).

Qualifications: Been burned too many times. Have the
scars to prove it. Once burned, twice shy.

P.S. - You didn't say what the primary purpose of
the data store was. Transaction processing, report
processing, other? These put different stresses
on a DBMS (which may or may not affect your choices).
e.g. if it's mostly report processing, would a nightly
feed from the legacy system satisfy the requirements?
Just another question.

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch