Databases and Fields

[original PM]

Morning All,

Can anyone of you very clever dev guys give me a steer on this?

We are working with our dev team on canonical data models for use in Biztalk etc.

So we have found that during our mapping session there are two pieces of data needed by downstream systems which we do not store at present.

However the other 40 pieces of data we have are ready to go.

My view is that we should get what we have ready to go and working and add in the two missing fields at a later point when the business have decided what it should contain.

But the dev team say that it takes as much effort to 2 extra fields to the data transfer scheme as it does to add in the first 40.

My view is they are taking the mickey however can I get an unbiased view on this from you lot?

Ta


oPM

[eek]

Morning All,

Can anyone of you very clever dev guys give me a steer on this?

We are working with our dev team on canonical data models for use in Biztalk etc.

So we have found that during our mapping session there are two pieces of data needed by downstream systems which we do not store at present.

However the other 40 pieces of data we have are ready to go.

My view is that we should get what we have ready to go and working and add in the two missing fields at a later point when the business have decided what it should contain.

But the dev team say that it takes as much effort to 2 extra fields to the data transfer scheme as it does to add in the first 40.

My view is they are taking the mickey however can I get an unbiased view on this from you lot?

Ta


oPM

I'm surprised that it just takes the same time again. Biztalk moves formatted xml documents around processes and end points, field changes result in new xml documents and requires everything being reconfigured.

Surely the solution is to include the two fields now (as optional parameters) and write everything to handle both scenarios.....

[original PM]

I'm surprised that it just takes the same time again. Biztalk moves formatted xml documents around processes and end points, field changes result in new xml documents and requires everything being reconfigured.

Surely the solution is to include the two fields now (as optional parameters) and write everything to handle both scenarios.....

yeah you would think...

but then extra code is being written....

generally I think they want to do the bare minimum and so requirements must be 100% nailed down and not change.....

hmmm

[eek]

yeah you would think...

but then extra code is being written....

generally I think they want to do the bare minimum and so requirements must be 100% nailed down and not change.....

hmmm

but no extra code is being written.

doing the work upfront to handle the two fields means that you only have to develop once and only have to test once (although granted you will be testing two types of input).

Didn't you use to do Biztalk development? Its always hated change for the sake of it.....