Future OFBiz Architecture - a marketing decision?!

[Paul Piper]

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: [phone]

Mobil: ([phone]

Fax: [phone]

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

 

 

ilscipio GmbH

Am Drosselschlag 7

D-35452 Heuchelheim

Germany

 

[Erwan de FERRIERES]

Le 26/03/2012 16:18, Paul Piper a écrit :
> 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.
>
Hi Paul,
this is a very interesting mail!
Your point is quite right about ecommerce and its location.

I'm not an eCommerce expert (and far from that), so would it be possible
to list the most needed functionalities, and the optional ones for this
? What do you think of creating detailed screens (as they are already),
and simplified screens (using only what is basically needed)?

While writing this, as you said, there is a need for a discussion on the
eCommerce component, what we want from it, what needs to be done, etc...
It has not been updated since a long time, and there is lot to do (an
actual theme?)

Cheers,

--
Erwan de FERRIERES
www.nereide.biz

[Jacques Le Roux]

From: "Erwan de FERRIERES" <[hidden email]>

> Le 26/03/2012 16:18, Paul Piper a écrit :
>> 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.
> While writing this, as you said, there is a need for a discussion on the eCommerce component, what we want from it, what needs to
> be done, etc... It has not been updated since a long time, and there is lot to do (an actual theme?)

It has been amended recently though. But I agree we need to discuss on it if people want really to make an effort on it

The place itself is indeed questionnable. And not only eCommerce, but also the other components which could stay in specialpurpose.
Why for instance moving the eCommerce to applications, if for instance, the POS or the Asset Maint stay in specialpurpose. Is the
concept of specialpurpose still necesary?

Jacques

[Jacopo Cappellato-4]

Hi Paul,

On Mar 26, 2012, at 4:18 PM, Paul Piper wrote:

> Apache OFBiz is marketed as an eCommerce System, but the eCommerce App is a
> special purpose application.

I actually disagree with the premise above; at lease the OFBiz project itself doesn't;  here is the "official" description from the project's website:

"Apache OFBiz (The Apache Open For Business Project) is an open source enterprise automation software project licensed under the Apache License Version 2.0. By open source enterprise automation we mean: Open Source ERP (Enterprise Resource Planning), Open Source CRM (Customer RelationShip Management), Open Source E-Business / E-Commerce, Open Source SCM (Supply Chain Management), Open Source MRP (Manufacturing Resources Planning), Open Source CMMS/EAM (Maintenance Management System/Enterprise Asset Management), Open Source POS (Point Of Sale), and so on."

Jacopo

[Olivier.heintz]

Le 26/03/2012 16:18, Paul Piper a écrit :

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

ERP System
When we are involved in trade show to present the Apache-OFBiz solutions
in France, we present an "ERP system" which can be use on 3 business cases :
for large company : a technical and functional Framework to be able to
build a dedicated solution
for sme company : a set of solutions, ready to use after a training and
setup phase ( these solutions used a lot of addons)
for very small company : a set (currently only one :-) of solution OOTB

eCommerce is always show as a component with a lot of success story
using Apache-OFBiz

If somebody are interested I can send directly some links to pictures
about our Stands.
>
>
> ·         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.
answer is in the previous one.
I'm ok with you, for small size company we need to be able to implement
without a lot of effort, so using what it has already done in previous
project, in our case addons, in future OFBiz-extras or similar thing.
So in the current situation +1 for your position

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

IMO current architecture is clear, Frammework + Application should be
the kernel, hot-deploy and special purpose are available to choose what
they want to use
>
>
> ·         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  Commerce 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.
For demonstration purpose, we have created dedicated component for a
profession (ex: consultant in a Service company or Sales reps, or ...)
to be able to show only what they need. These component have mainly
dedicated menus and portal page.
With this approach, each component should have only feature about it,
but show all what it's possible.
>
>
> 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 he 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.
on back office, using portal page and portlet could be a answer but I'm
not sure for eCommerce
>
>
>
> 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
It very important to contribute about Marketing support, thank you to
starting this discussion. Some of our marketing support can be send (not
on mailing-list but directly, because there is our trade mark on it)
>
>
> Cheers,
>
> Paul
Olivier

PS : all my answers are oriented on the marketing aspect (What we tell
to our prospect ), and certainly not to argue about other discussions ;-)

>
>
> ---
>
> Paul Piper
>
> Geschäftsführer
>
>
>
>
>
> Web:<http://www.ilscipio.com/>  http://www.ilscipio.com
>
> Tel: [phone]
>
> Mobil: ([phone]
>
> Fax: [phone]
>
> eMail:<mailto:[hidden email]>  [hidden email]
>
>
>
>
>
> ilscipio GmbH
>
> Am Drosselschlag 7
>
> D-35452 Heuchelheim
>
> Germany
>
>
>
>

[Nick Rosser]

Paul,

Interesting comments, some very much in line with our thoughts at Salmon
LLC -- and similar to some themes that we've posted about previously.
See some of my thoughts, interesting thread ...

Best Regards, Nick Rosser [hidden email] O: 516.742.7888 x221 C:
516.901.1720

On 3/26/2012 10:18 AM, Paul Piper wrote:

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

It is clearly both and we have built solutions for both eCommerce
focused and back-end ERP solutions. I don't see OFBiz being marketed as
an eCommerce solution (why do you think that?), and many of the
user-list posts are clearly ERP targeted. And what is an eCommerce
system? A solution that only takes orders via the dot.com site? Or a
solution that can print packing slips and shipping labels? And if it can
do that does it track inventory and order-status? And warehousing? And
what about accounting? And why not have an interface for telephone
orders? IMO, the line is very fuzzy here, it depends on the client,
their vision, their approach to multi-channel, their budget, and the
integrator.

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

OFBiz has never been marketed as a ready-to-go solution. It is a
complex, comprehensive framework that solves many problems for many
companies. As such, I do not think that it is suitable for a small
company, unless that company is willing to battle thru the OOTB
interface and run their business -- this is clearly possible, however
unsuitable the interface is for them to run their business. Clearly this
has happened with many implementations and I'm sure that these companies
get by just fine in many cases, with support from an OFBiz partner or
the community. For large companies it can be an attractive solution,
either because they have in-house resources to do the required
customization or can pay a partner to do so. You could argue that for
large companies we are now competing with other products but many large
companies are very cost conscious or simply like open-source solutions.
The sweet spot, imo, is the medium size company ($20M - $1B). They are
looking for a comprehensive solution and have the pockets to pay for
customization that will help them save money and justify the cost.

You make mention of Hybris, Intershop, IBM Websphere and Magento -- all
eCommerce solutions. We have done IBM Websphere solutions and they are
not for the weak of heart. It's a big, time consuming implementation and
upgrading to the next version is almost as big as the original project.
Hybris, although touted as a more nimble solution is not much different.
Magento can be used for smaller eComm solutions but when you get into
more sophisticated requirements the cost gets surprisingly close to
other big brand vendors. Again, we have personal experience with all of
these scenarios.

If we are focusing on eCommerce you may be interested in our BigFish
solution. It's a extension to OFBiz that really does focus on eCommerce.
It bundles our experience and best-practices into a flexible,
comprehensive solution. For more info check out
http://bigfish.salmonllc.com -- the Fashion-House "demo" is a good start
-- both the eCommerce and "Admin Module" are worth a look.

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

Again, this is because it is a framework and not intended to be a
ready-to-go solution. I've come to terms with this, having had similar
thoughts to you in the past. The intent of the OOTB interface is to
illustrate ALL the functionality and services that are available. If any
are hidden from the UI then it takes even more technical-savvy to figure
out if something is supported by a service. It's much easier to walk
thru the UI and discover functionality.

It seems to me that many in the community have developed just what
you're looking for -- business domain focused solutions. Getting a
directory of all available domain specific solutions would be valuable
to all as a starting point for a domain specific solution. BUT, in
reality it would be a nightmare -- there is always a twist in what we
need to implement for specific clients. Always, it's the nature of the
ERP beast.

If you're talking specifically about eCommerce then our BigFish solution
would definitely be of interest to you.

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

I don't think anyone would disagree that improved documentation, better
examples, better architecture, better coding standards, more domain
specific implementations, would all go a long way to improving
everything. Again though, when talking about ERP this is a very complex
domain to solve. There are just too many variables to handle all
requirements. At Salmon LLC, our experience has been bumpy getting
up-to-speed but now that we have the expertise there's not much we can't
do for a ERP solution. And we have happy clients, managing ~$100M
businesses, using OFBiz to run their business. ERP is "bet your
business" software -- non-trivial, difficult, complex, and scary. This
is true from small companies to the very largest and there are many
stories of companies being hurt by poor implementations (all the way to
using SAP and having multi-million dollar implementations).

You've focused on eCommerce in the comment above. Check out BigFish --
this is exactly what you're looking for -- I'd be interested in your views.
>
>
> 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
>
>  
One last thought about eCommerce, re-iterating the multi-channel
requirements that many companies have to deal with. In order to fully
support multi-channel you can't just have the front-end dot-com
implementation. Multi-channel demands that ALL channels (eComm,
customer-service interface, store POS, B2C and B2B) have a view into the
the same system. They can all check inventory, all place orders, all
orders come together for fulfillment, all flowing into accounting etc.
So, this blurs the line even more when discussing eCommerce vs ERP. And
with OFBiz we have it all :-)

>
> Cheers,
>
> Paul
>
>
>
> ---
>
> Paul Piper
>
> Geschäftsführer
>
>
>
>
>
> Web:<http://www.ilscipio.com/>  http://www.ilscipio.com
>
> Tel: [phone]
>
> Mobil: ([phone]
>
> Fax: [phone]
>
> eMail:<mailto:[hidden email]>  [hidden email]
>
>
>
>
>
> ilscipio GmbH
>
> Am Drosselschlag 7
>
> D-35452 Heuchelheim
>
> Germany
>
>
>
>

[Christian Geisert]

Paul Piper schrieb:
[..]

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

Good point. But for me OFBiz is an ERP System (with a strong ecommerce
component). It started life as an ecommerce system AFAIK and that's
still the way it is most used until today.
I think the reason is that it's quite different to sell ecommerce or
ERP. Companies are very reluctant to switch ERPs (IIRC the average life
span of an ERP is more than 10 years in Germany) and one of the most
important selling points for ERP is security ("Nobody gets fired for
buying SAP"). That's the classical chicken egg problem for OFBiz,
I can't remember how many times I've been asked "But who is using the
accounting component in Germany?"

"ERP" is a huge market and I see a very bright future for Open Source
ERP and therefore for OFBiz (ok, I'm saying this for quite some time now...)

Christian

[Pierre Smits]

Dear Paul, and all others providing feedback before me,

Here are my thought on this subject and other mail treads that have spawned
recently regarding the road ahead:

Is OFbiz an eCommerce solution or an ERP system?

I believe OFBiz (the product) is an eco-system of Business Applications
supported by a sound framework and maintained by a community of developers
and System Integrators. For me, it doesn’t matter whether the individual
implemented eco-system consists of nothing but the ecommerce solution on
top of the components in the ‘applications’-folder and the framework or
that such an implementation consists of a well extended HR solution + some
specials (to name a few examples. It enables us to adhere to any scenario.
That is the strength of the product.



When I implement OFBiz at a customer’s where the focus is on secondment and
project management + HR functionality and FICO, the first that get moved
from ‘Special Purpose’ to ‘Applications’ are the Scrum and Project Mgr
solutions. And for that implementation all redundant components are removed
(e.g. pos, ecommerce, ebay and such, but also example). We want to deliver
lean solutions.

If the focus of a customer is B2B ecommerce we remove what is unwanted
also. But in all cases, this is done in consultation with the customer.
Customer satisfaction is king!



Having said that, I do believe that the product has reached a state where
there is needed more than just the love and convictions of developers. It
needs clear and elaborate statements on functionality, sound examples that
are well documented and explained. It needs explanation on possible
implementation scenarios and more.



*Re eCommerce*

I believe that at the moment this can best be positioned between ecommerce
add-on in WCM solutions, like WordPress, Joomla, Drupal etc, and on the
other side of the spectrum solutions like Magento.



In the lower part of the spectrum (WCM-plugins) besides the webshop-plugin
the customer needs also plugins to deal with logistics and payment. And
what they get, besides a shop front-end, is a poor solution regarding
catalog/product mgt, price ruling, promo’s etc and in house logistics
(warehousing, picking and packing), combined with a poor separation of
responsibilities and functions (organisational).



I also believe that the eCommerce eco-system, given that it will get a
dedicated visionary team of business consultants and developers, can be
enhanced to compete with solutions like Magento et all. And yes and again,
it all has to to with customer expectations and satisfaction. Given that
little love has been spent on the theme and was left to the individual
System Integrators, the proposition is difficult to make.


Contradicting architecture

I agree that current architecture is hindering growth. Having apps in the
‘applications’, ‘specialpurpose’ and ‘hot-deploy’ is a matter of taste. I
guess it was decided upon in the early days of the project and since then
been regarded as cast in stone.

But what is more important is the fact that a number of screens and forms
in applications.are dependant on screens and form in other applications
wherever they are found. Reuse of services I agree to, because for that is
the intention of the solutions in the framework (and found in the framework
folder). But each application should be as much self providing (self
contained?) as possible, because each application is following a different
business purpose and should therefore be able to be run as contained as
possible. Having this it would help to find per application that dedicated
team of business consultants and developers to provide the love and the
roadmap for each. And that is also required from a marketing point of view.
What applies to the eCommerce solution also applies to any other app (see
above).



Yes, current setup of the community where we have a dedicated few that
commit to everything (our committers, who deserve thanks and respect for
the effort they spend assisting us) and where there are to few who have
their focus on any specific application, hinders the adoption of OFBiz. But
recent discussions in this forum have gotten/are getting us on the same
page with respect to the heading of the community and the product. And I
believe that it is not only a destination, but also a journey.



Having applications in either sub projects in current OFBiz community setup
or outside and under no guidance/control of the community is again a matter
of taste. But I believe that having any application as dedicated sub
project will enhance the community aspects more (despite the increase in
paperwork) than having them as separate projects on another platform.



Any application needs to serve a business purpose/need, no one will deny
this. Any enhancement in functionality, change of setup and/or bug fix
should serve a community purpose as well. I believe in the past some
misjudgements have been made in the community. When contributors provide
feedback, enhancements, improvement and bug fixes their products have to go
through a vetting process by their peers and the committers.

But I have seen committers dumping code into the product without consulting
the community (contributors and committers) on the need (business and
community) and technical adherence to the framework for it. This is more of
an adoption hindrance than lacking technical maturity (which I think it
has). Both by peers and customers, because if we (the community) not act as
one, there is no community that supports the product
Make it accessible

This is more a marketing issue than a technical one. OotB, OFBiz enables
any of us to showcase eco-system functionality tailored to specific target
audiences, whether they be marketing and eCommerce, warehousing/logistics
oriented, FICO or Project Mgt/Workflow oriented. It is just a matter using
the right demo account for the need required.



When you show all while demoing with the admin account you’ll get
information overload and a difficulty in acceptance of any specific
solution.

My 2cts

With my utmost regards,


Pierre Smits

[Jacques Le Roux]

Hi Paul,

Inline...

Paul Piper wrote:

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

From the main page on site <<Apache OFBiz (The Apache Open For Business Project) is an open source enterprise automation software
project>> But I think you have a point, a lot of users are actually using it primarily because they needed an eCommerce site.
It seems it's mostly a marketing decision.

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

Truth to be told, and I think it derives from OFBiz history which was more intially backed by independents working on smaller
projects than now OFBiz is sometimes used in.

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

A good way to see it is described by Moqui: http://www.moqui.org/ even if I'm abusing here (they are not the same but the same
"Decorator Pattern" is used)

> o   Framework - the basic stuff, entities, services and such

Moqui Core

> o   Applications - General Applications that play a role in most
> environments

Moqui Mantle

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

Moqui Crust

> o   Hot-Deploy applications - your own application/modification

Moqui Crust

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

Apache OFBiz is not *ONLY* an eCommerce Application. View from a web agency it is. But there are much more type of actors which are
using OFBiz.

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

Those can be used out of the context of a typical  eCommerce application (B2B for instance).

>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),

Mixing Mantle and Crust is not a good idea IMO. Keeping layers clearly separate is better IMO. OFBiz is a good tools to learn not
only itself but a lot of good practices. We should keep that in mind also...

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

This is the idea of the coming slim down action using Apache Extra as external repository.
*Important note:* BTW I think using svn external could help http://svnbook.red-bean.com/en/1.0/ch07s03.html to keep Extras
components in sync

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

I prefer ant+Ivy over Maven. I also read a bit about BuildR: http://buildr.apache.org/  it uses Ruby...

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

This could be discussed indeed and has been already in the past which ended in the current status quo. What we could do rather is
explaining to user why it's like that on main OFBiz site page and especially with a note on all main application pages. I found that
adding small notes (few lines at max) in screens can help much new comers.

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

Ha you see, you are really focused on web agency actitivy when I have a wider view. So the comment about stands really for the
ERP/backend side. For the eCommerce I tend to agree with you that some parts could be removed (forums, pools, blogs). But even ther
I'd prefer to keep them and explain why they are there and how easy it can be pruned (still few lines)

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

I don't agree, but we could indeed have a common slimed down eCommerce application (named tinyecommerce?) in Extras, which is the
way we are considering to handle things now. I say common because I know few companies have already their. Now this would need to
come on a common ground. Could be a new thread...

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

The tinyecommerce could avoid this. Each aplication README could explain why and how..

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

OOTB the uis are demos, nothing else. But yes, we should try to improve not only new comers experience but also reusability across
projects.

> 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

Looking forward :o)

Jacques

>
>
> Cheers,
>
> Paul
>
>
>
> ---
>
> Paul Piper
>
> Geschäftsführer
>
>
>
>
>
> Web:  <http://www.ilscipio.com/> http://www.ilscipio.com
>
> Tel: [phone]
>
> Mobil: ([phone]
>
> Fax: [phone]
>
> eMail:  <mailto:[hidden email]> [hidden email]
>
>
>
>
>
> ilscipio GmbH
>
> Am Drosselschlag 7
>
> D-35452 Heuchelheim
>
> Germany

[Jacques Le Roux]

Pierre Smits wrote:
> Dear Paul, and all others providing feedback before me,
> Contradicting architecture
>
> I agree that current architecture is hindering growth. Having apps in the
> ‘applications’, ‘specialpurpose’ and ‘hot-deploy’ is a matter of taste. I
> guess it was decided upon in the early days of the project and since then
> been regarded as cast in stone.

Not at all, it's all about layers: specialpurpose rely on applications which rely on framework. In a perfect world there should be
no dependencies of the upper layers upon lower. Unfortunately framework dependencies upon applications has been introduced and this
is the main root  all these discussions. Please don't make assumptions and keep focused (stand for both Paul and you Pierre ;o)

> But what is more important is the fact that a number of screens and forms
> in applications.are dependant on screens and form in other applications
> wherever they are found. Reuse of services I agree to, because for that is
> the intention of the solutions in the framework (and found in the framework
> folder). But each application should be as much self providing (self
> contained?) as possible, because each application is following a different
> business purpose and should therefore be able to be run as contained as
> possible.

On that I have mixed thoughts. I like to be able to do it and it saved my day many time. Also we could consider Jacopo's proposition
to have only one big ERP application (only one erp component?). But, like some others, I prefer to keep the current structure and
have separated components. I don't see the possibiliy of being able to use cross component features like something hindering me to
work properly, actually quite the contrary: it keeps OFBiz DRY. This said there are some flaws like
http://markmail.org/message/g2lp3n4vovgelqyf and http://markmail.org/message/37k4bg7ajlkaje3n  (not sure I opened the Jiras I
promised...) but those as not specifically inter apps

> Having applications in either sub projects in current OFBiz community setup
> or outside and under no guidance/control of the community is again a matter
> of taste. But I believe that having any application as dedicated sub
> project will enhance the community aspects more (despite the increase in
> paperwork) than having them as separate projects on another platform.

+1

> Any application needs to serve a business purpose/need, no one will deny
> this. Any enhancement in functionality, change of setup and/or bug fix
> should serve a community purpose as well. I believe in the past some
> misjudgements have been made in the community. When contributors provide
> feedback, enhancements, improvement and bug fixes their products have to go
> through a vetting process by their peers and the committers.
>
> But I have seen committers dumping code into the product without consulting
> the community (contributors and committers) on the need (business and
> community) and technical adherence to the framework for it. This is more of
> an adoption hindrance than lacking technical maturity (which I think it
> has). Both by peers and customers, because if we (the community) not act as
> one, there is no community that supports the product
> Make it accessible

It's more the lack of manpower wiht enough knowledge and committment (ie really active committers). But yes there have been even
almost fight in some cases. Also a reason why the current action is taking place IMO. We need to cure some things...

Like for my answer to Paul, this is only my POV and not the PMC or committers....

HTH

Jacques

> This is more a marketing issue than a technical one. OotB, OFBiz enables
> any of us to showcase eco-system functionality tailored to specific target
> audiences, whether they be marketing and eCommerce, warehousing/logistics
> oriented, FICO or Project Mgt/Workflow oriented. It is just a matter using
> the right demo account for the need required.
>
>
>
> When you show all while demoing with the admin account you’ll get
> information overload and a difficulty in acceptance of any specific
> solution.
>
> My 2cts
>
> With my utmost regards,
>
>
> Pierre Smits

[james_sg]

Is OFbiz an eCommerce solution or an ERP system?

OFBiz is an eCommerce solution with some ERP functionalities.