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 [email protected] 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: (+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
