incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David E Jones <>
Subject Re: Business Framework Project
Date Wed, 23 Jan 2008 08:13:23 GMT

I'm not sure if this is the best forum for this discussion, but it's a  
good discussion and I also can't really think of a better forum!


On Jan 22, 2008, at 5:31 PM, Ahmad Khalifa wrote:

>> There are various commercial vendors doing this sort of thing. Most  
>> are aimed at having doing infrastructure for a centralized ASP- 
>> style environment, ie where there is one big application and people  
>> build or extend apps through web-based interfaces and everything  
>> lives on the server. The ultimate in lock-in, and an nice enabler  
>> of over-centralization (which I think most open source proponents  
>> realize the danger and downside of...). That's a good motivation  
>> for database driven business data structures, logic, screens, etc.
> What could be considered as lock-in or over-centralization from one
> perspective, could be looked at as being simplifying things or  
> reducing
> costs from another perspective.

Yes, the siren song.... From a due diligence perspective the promise  
of ease causes a good investigator to be all the more wary of what is  
lost in order to get that ease. It's easy to forget that compromises  
made in the name of ease often lead to more compromises and eventual  
full compromise.

> Think of CRM/ERP/Accounting/Payroll/HR/etc.. just compressed into one
> system, this would certainly promote less Excel sheet usage :)

Agreed, very valuable. This is one of the very important things we are  
doing with OFBiz.

> The basic model of having 1 repository of customers is inherently  
> better
> than having multiple repositories at several systems, with data
> fragmented allover, and backend migration/integration processes  
> running.

This is another thing we are doing with OFBiz. The focus is on a  
single architecture and set of lower level business artifacts that you  
can build anything with. For companies that can afford the  
customization this means they have the ERP/CRM/ecommerce/etc/etc that  
they want. For companies that can't afford the customization there is  
already a growing set of vertically oriented solutions that are more  
tuned for out-of-the-box usage.

> 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  

> 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  

- Realistically you have to pay someone to support systems even if you  
don't do it yourself (and this is a good thing to pay someone to do...  
hosting companies that have expertise for different apps are a genius  
business model).

- The only way to reduce user training that I know of is to have  
applications that are built to guide users through the processes the  
business wants. That means the applications must be tuned to the  
specific business and if that business wants to change it must change  
its apps, or at least written for a particular type of business and  
leave in a bit of flexibility and require a little bit of training.

- If you have a good, complete system you don't need too many  
integration efforts, but some are almost always needed. For example  
very few companies do payment processing or shipping on their own, but  
fortunately once you have a small set of integrations in place  
additional work is not needed.

- If you can find clients that don't need data migration count  
yourself lucky! Usually unless you have a new company or a company  
that has serious budget limits and can't afford it, you'll need to get  
the data from the old system(s) into the new system (hopefully  
singular there...).

>> BTW, Compiere actually works more or less this way. Ie, things are  
>> heavily database-driven.
> Yup, but they're mainly ERP, and they work with Oracle databases and
> some postgreSQL fork. Plus, they don't have the extreme customization
> abilities discussed.

Yeah, Compiere is an "interesting" project. The architecture is mostly  
old-school client-server style (ie client apps talking to a database,  
the only centralized logic is in stored procedures). There are also  
many quirks, as is natural when the design and development is mostly  
done by one person. It is admittedly impressive given its background  

>> If you get to the point where you start looking at data modeling  
>> and the logic tier stuff, feel free to collaborate with us at  
>> OFBiz. More eyes on this stuff is always a good thing! Okay, well  
>> 98% of the time. ;)
> 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.

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.

> 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.

Of course, with enough design an engineering I have strong faith that  
we as humans can make anything work, and work well. In other words it  
should be possible to build tools and such so that you get all of the  
benefits that are inherent with files (and all of the tools we have  
for working with them) with your data stored in the database. BTW, I'm  
using the term "data" very loosely there to include code, data  
structure info (meta-data), templates, etc.

> Anyway, I really hate the idea of having /Yet Another Framework/,  
> but as
> we discussed, there is no open source alternative. This is only  
> found in
> commercial applications.

In spite of my biases I am VERY for diversity in approaches and good  
efforts to explore the viability of each. I'd love to see other  
frameworks developed in the open source world that compete with the  
OFBiz Framework. There certainly are many out there, but I mean really  
compete and give the tools we're using a good drubbing when evaluated  
for productivity in design, implementation, maintenance, and  
customization. One of the big metrics there is the volume and  
complexity of the business level artifacts. That's where using tools  
that are special purpose for business applications provides a huge win  
over generic tools, like making everything a Java class.

Eventually one starts feeling something like: "if I have to map one  
more thing to an object that isn't anything like an object just to  
make it possible for that to work with all of these other things that  
are mapped to objects but really aren't anything like an object, I'm  
going to lose it!" In that case losing it could mean sanity, but if  
often also means flexibility and understand-ability because as  
concepts are mapped to something that is not the same, some things  
don't make it through the mapping and the capabilities are simply  
"lost in translation".

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.

I don't know about others in the OFBiz community, but for my part if I  
see technology that does lead to smaller and less complex business  
level artifacts I'll take a close look at it and evaluate other things  
related to efficiency and productivity for development, maintenance,  
customization, et cetera and if it beats the OFBiz Framework then it's  
time to replace the OFBiz Framework.

So, whatever you do, please don't let my comments discourage you, and  
I hope they don't come across as too confrontational. I really wish  
you the best success with your efforts and I hope that you'll be able  
to succeed where so many have failed in really designing and building  
something that delivers on this intent.

And I'm guessing you'll agree that doing so in the Apache way with a  
focus on collaboration through community building is the route most  
likely to get your there.


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

View raw message