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!
So....
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
capability".
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.
- 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
though.
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.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
