Well, as some of you may know, I have been lurking around the mailing lists
for quite some while and added some input here and there. With ilscipio
(www.ilscipio.com/en) we are currently focusing on many aspects of Apache
OFBiz and try to contribute a little more to the community in the near
future. We are happy to say that our clients love Apache OFBiz and we are
currently either in the talks or already in collaboration with some global
players. 

 

Through the past few years, I have come to a few thoughts on the
marketability of Apache OFBiz, especially with regards to the architecture.
I would like to discuss these openly with you, since I got the feeling that
there are a few things that we as a whole should change in order to push
Apache OFBiz further. This does in no way mean that I am unsatisfied with
the status quo (clearly Apache OFBiz is an awesome piece of work with a
great design underneath), but rather that I think it may not be marketed
correctly or be as appealing as it could be. 

 

Here is what I think:

 

·         Is Apache OFBiz an eCommerce or an ERP System?

Apache OFBiz is marketed as an eCommerce System, but the eCommerce App is a
special purpose application. This doesn’t mean that it cannot be both, but
if you are marketing Apache OFBiz as a big eCommerce System (competing with
Hybris, Intershop and IBM Websphere on the market), then it should focus on
that. Don’t get me wrong, the overall architecture underneath aims at being
great for much more than the eCommerce App (clearly it is aiming to be used
for all business processes), but I think here is where we fail to show
Apache OFBiz at what it is. By losing focus on the eCommerce aspect of it
all, we fail to market it as a whole. 

 

·         Target company size & clients

I think there is a big misunderstanding on our target group as a whole.
Apache OFBiz reaches a complexity so that it comes unattractive for small
size businesses. True, it features a lot for low costs, but then again, the
backoffice is overwhelming and customization takes a lot of effort so that
small size companies simply cannot implement Apache OFBiz successfully. If
they go that route they will have to pay for it with a lot of labor and or
by paying a lot of money. That is, in my opinion, why OFBiz competes with
Hybris, intershop, IBM Websphere and other rather big systems and is not
competing against Magento. 

 

·         Contradicting Architecture

The current architecture defines framework, applications, special-purpose
and hot-deploy apps. Whereas the definition being a little vague on:

o   Framework – the basic stuff, entities, services and such

o   Applications – General Applications that play a role in most
environments

o   Special Purpose – hey look, you can do this, too (more of a demo
implementation or lesser used applications)

o   Hot-Deploy applications – your own application/modification

I have no problem with Framework & Hot-Deploy, but I believe that the
current way Applications and Special-Purpose are used is at least a little
misleading. If we assume that Apache OFBiz is an eCommerce Application then
we must assume that the eCommerce Component is a core element of the
architecture. It isn’t. The same applies for payment partners and
distribution channels. All of these are special purpose applications. I
believe this goes hand in hand with a mind unset on whether Apache OFBiz is
an ERP or an eCommerce System. I would argue that either eCommerce is added
to applications and modified to be self-contained (I will explain this a bit
further in my next statement), or that eCommerce and all other special
purpose applications are dropped in favor of a modular design in which third
parties provide a store as a plugin to the Apache OFBiz framework. In case
of the latter Apache OFBiz should drop the eCommerce approach and rather
focus on creating a great eCommerce or ERP framework. It would also require
proper release planning and rollouts. Here a switch to maven could be
beneficial since the dependencies are easier to maintain – but that is
another discussion.

 

·         Making it accessible

 

On a user level, I believe that OFbiz has a problem with showing too much to
the general public. Sure, OFBiz can do all a client would ask for, but the
problem is that the client doesn’t see it. He sees all functions at once and
is hence losing out of sight what he was looking for. This is the true
reason for why all eCommerce Agencies start working on their own shop design
and drop functions wherever they can. It simply isn’t attractive to
outsiders otherwise (though again, the structure itself and the
functionality it comes with is where ofbiz shines). I personally would argue
that keeping it down to a bare minimum could benefit all. Perhaps we could
create a list of supported functions rather than trying to show off all of
them at once. The functions can remain as is. The same can be said about the
backoffice, where we show off functionalities that aren’t of interest to the
key-users  (a marketing person is only interested in the marketing app, a
product manager only in the product manager etc.). Here we fail, by keeping
cross references to other apps, instead of opting for intuitive wizards or
forms that the user can rely on. Simplicity is key.

 

On a developer level, OFBiz has a problem with keeping it easy to work with.
The structure in its own is designed for reusability, but at the same time
OFBiz fails to make it easy to customize. The current way widgets are used
are confusing to many outsiders – the cross references are simply
overwhelming. So I would argue we need better tools and opt for a clear
design goal of each application. At the same time the confusing architecture
of the eCommerce application makes it more difficult to customize the shop
than it has to be. Most people will probably look at OFBiz as an alternative
to another eCommerce System. We basically show off all the eCommerce App can
do by providing a “demo” with the special purpose application. However, we
made it so that the eCommerce app is not self-contained, meaning that she
heavily relies on screens and widgets that derive from the other
applications. This means that we have a conflict of interest here: we want
people to customize, but at the same time they cannot do that, because they
will affect the other core applications. This is the sole reason to why all
developers either begin to copy the ftls into the eCommerce application or
another reasons why eCommerce agencies build their own version of the store.


 

There is probably a lot more that I could add, but I really want to start a
discussion with you guys. As I said, I myself and ilscipio are really eager
to contribute more in the future and we would love to push OFBiz into a
direction that is beneficial to all of us J 

 

Cheers,

Paul

 

---

Paul Piper

Geschäftsführer

 

 

Web:  <http://www.ilscipio.com/> http://www.ilscipio.com

Tel: (+49) 611-94589441

Mobil: (+49) 176-63283066

Fax: (+49) 611-94589449

eMail:  <mailto:[email protected]> [email protected]

 

 

ilscipio GmbH

Am Drosselschlag 7

D-35452 Heuchelheim

Germany

 

Reply via email to