incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ahmad Khalifa <>
Subject Re: Business Framework Project
Date Wed, 23 Jan 2008 13:18:55 GMT

David E Jones wrote:
>> As you mentioned, yes, there *are* various commercial vendors doing
>> this, but no open source has this capability.
> I'd be interested to hear more of what you had in mind for "this 
> capability".

The ability to customize anything and everything in the application
at a higher level than Java and XML.

>> Consider a small-medium business that has an ERP system, and one day
>> decides that they want to get a CRM system to track their sales force.
>> Which would be the best scenario of those?
>> (A) - A typical CRM implementation with data migration/integration work,
>>      user training, More systems to support.
>> -OR-
>> (B) - A small CRM implementation with no data migration/integration, not
>>      much user training, no more systems to support.
> You've lost me a bit here.... It is definitely nice to avoid things like 
> data migration and integration and user training and support of systems.

I certainly didn't mean that scenario (B) will make the costs Zero. I
meant that with the second system -- CRM -- there will be much less
work to do outside of the implementation of the CRM itself.

>> What do you mean by 'start looking at data modeling'?
> What I mean is actually designing how to store information for things 
> like products, orders, invoices, payments, shipments, 
> customers/employees/suppliers/etc, quotes, requests, and so on.

Well, thats already done. I have looked at how exactly to model and
extend several business scenarios. Remember, in my first post I
> Note, The project has a working codebase.

> Or is your intent to just create a framework and not get into business 
> level artifacts? Don't read too much into that question: that's a very 
> common and valid approach and I don't mean to suggest that you should if 
> it's not your intent.

Remember, in my first post I mentioned:
> There is also an incomplete CRM-like implementation.
It *is* my intent to build several apps on top of this framework, to
make is easier to implement. That is what I think that this project
could benefit from OFBiz.

>> Are you still skeptical about using database to store application
>> objects? Consider moving the component-load.xml file to the database
>> and having a load-on-demand button somewhere. How much easier would it
>> be for users to activate/deactivate/upgrade components? and no downtime!
>> This would be exactly like Drupal's Module management system.
> I am still skeptical about it, yes. It definitely sounds nice at first, 
> but I've been through cost/benefit comparisons for doing this with all 
> sorts of different types of data and even tried a number of these 
> things. Some things just seem to work better in files and other things 
> seem to work better in database records.

Perhaps more details into how this framework does things would help
convince you??

> I think you're looking at going in the same direction that we are with 
> OFBiz. That's a great thing to see even if, or rather especially if, the 
> approach for getting there is very different.

Yup, same direction.

I'm trying to propose a different approach to doing things that IMO
would be much easier than OFBiz. If you're not sure that the approach 
itself would be able to deliver the same functionality, then we need to
discuss that before getting into which is best.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message