Chris Howe wrote:
Thanks for the feedback Jacopo!
questions inline...
--- Jacopo Cappellato <[EMAIL PROTECTED]> wrote:
However we are not trying to capture the whole universe in our data
model and processes - not now, by the way :-)
Why not now :-) ?
Because we haven't been able to recruit any omniscient contributors to OFBiz
yet. If you know anyone good who is up for the job, please let us know!
And there are *huge* advantages of limiting our scope to some
assumptions: OFBiz, as an ERP system, can be used by a Company, with
many divisions under it (possibly playing various roles in the supply
chain) etc... but where you can pretty clearly identify who are the
suppliers, the customers, the agents etc... (and combinations of
these) what are purchase orders and what are sales orders.
That really is the crux of my question. What are the _huge advantages?
If it is just convention that allows ease of writing applications or
performance related, would denormalizing the value be more prudent
(having the value in the theoretical correct place AND in the ease of
use place)? Or are there other advantages that I'm overlooking?
IMO, in an ERP system, data is data and isn't particularly fascinating.
The application(s) that read and process the data are what bring about
the value and insight of ERP systems. Having an arbitrary scope turns
the fascination to the data and has its dangers. For instance, I think
the redundant structures and logic to support a quote and a return
order as well as the structures used to maintain a supplier's pricing
illustrate that danger. (Note: I'm not suggesting those are bad
implementations or don't get the job done, just more costly to create
and to maintain).
In addition, I think that scope puts a limit on the creation of
additional applications. Competitor Intelligence and Customer
Intelligence applications would require building out redundant entities
and redundant logic because they go against the scope.
How redundant are these really? I'd ask you to review the data models one more
time. They really don't have many similarities beyond things like the
header/item and role patterns, and those are patterns.
If we were working with an object model we could have a base object that
handles those things and extended objects for orders, returns, shopping lists,
requests, quotes, and various other things too. But it's a relational data
model so it doesn't work that way, and very much no, we don't want to go down
the road of trying to make it object oriented and doing the O-R mapping and
such. That is a huge overhead easily an order of magnitude higher than the
small redundancy in model and code we currently have.
I am very much against trying to make a consolidated model of this. We've discussed this before and my opinion has not changed. The order model is WAY more complex than the return or quote models, and even those have very different purposes and have some fairly different data needs and it would make the project in general far more difficult to understand and work with and customize if we tried to consolidate them.
The main reason for this is that for each use of the model you would end up
with a whole bunch of fields or even whole entities that are not used or that
might be used in special circumstances, but when? For example the order model
is very complex and has far more complex requirements than requests or quotes
or returns and if we used the same model for these everything we do with
requests or quotes or returns would be made artificially and unnecessarily
complex, which means right there it's a bad design decision.
For customization and refactoring and so on over time it would also cause big
problems. This goes back to the omniscience problem... If we could have a
perfect, meet-all-requirements model right now we would. But we really can't.
So, we need to plan for the fact that things WILL change in the project, and
when implementing for specific clients or industries things will also HAVE to
be changed. That's life, and so in the framework and applications (of which the
data model is a part) we've tried to design for that, and improve the design
for that iteratively over time.
-David
