Hi,
I'm a ERP modularity Fan,
My ideal ERP would be a Kernel, smallest as possible but with all which
is common to all possible business applications,
- Technical Framework (only on technical choice by domain)
- Common Data model, Entities and fields
- Common Services
- Common User interface
- and whatever is detailled in
(https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision)
And a lot of "Component" (or addons or pluggin or functionality or ...)
which are easily installable (dependency management) to have OOTB ready
to use applications.
With that, Company or Community could propose some OFBiz "Distribution"
Since I have contributed (2003/2004) to OFBiz I'm convinced OFBiz
project can become the ERP I dream about :-). Every last Jacoppo (and
answered) mail threads are very good questions-reflexions to define the
road to get it ;-)
I try to make short answer to each thread to be more readable, and tried
to answer mail by mail to be able to be more precise.
This mail is only a introduction before the next 4 mails.
PS: I'm currently finishing a lot of contributions about portlet
management and ofbiz screen migration to portlet, first proposal will be
proposed next week
Le 15/03/2012 10:20, Nicolas Malin a écrit :
Hi,
At this time, applications components embedded functional framework
and business oriented (massively B2C) and aren't user friendly.
I possible solution will be have a dedicate application components for
only Consultant or high level user that contains only the functional
framework (with business process cleaned) and for end user an oriented
business components
Exemple :
application /
content
humanres
manufacturing
marketing
order
party
product
workeffort
specialpurpose :
cms
edm
ecommerce
order-b2b
crm-b2b
...
The business components contains (in a beautiful world) only business
service process and simplified screen.
We work with Apache OFBiz on hight parameter ERP with dynamic (by
jquery through screen engine) reusable screen based on portlet and
portal page. Own idea is, the application components give a portlets
list that business components use to configure their portal page.
I'm not a modularity fan. For the technical framework, is great but
I'm much more mixed to use on functional framework. Integration
problem will not resolve easily.
Nicolas
Le 14/03/2012 23:04, Tom Burns a écrit :
Adrian / Jacopo
While thinking about a refactoring the OFBiz Architecture you
may want to look at http://www.aosabook.org/en/intro.html. The book
is all
about Open Source architecture. In particular see the chapter on
Eclipse, the
ultimate open source component framework, Eclipse is the perfect
environment to
implement Adrian's ambitious vision.
However the most pressing problem in OFBiz, given the
available resources, is not the architecture, rearranging the
components or refactoring
of what in Moque would be the Core / Mantel (i.e. a scripting
framework etc.).
Rather the problem, as your most recent post to this thread
suggest, is the short comings in the OFBiz Crust. OOB the user facing
applications are difficult to understand, quirky and do not support
needed business
requirements. Just ask yourself would you go into a meeting with
Steve Jobs ghost
with these applications?
On the OFBiz home page "What is Apache OFBiz" the
focus is clearly ERP. The bullet points advertise OOB application
functionality. The business applications should be easy to use,
robust, and well
documented. This will require more attention to business requirements,
providing a consistent set of defined services, adherence to
documented UI best
practices and well written and better presented user help.
All of this is possible without doing more additional work
on the Core / Mantel.
I would be happy to contribute to an effort to improve the
user facing applications if there is support from the committers.
I see these applications as falling into two categories. Applications
that are common to most businesses and domain specific applications.
This
follows the pattern laid out in the two DMR Books. The former, more
general,
category should get the most attention. Those applications include:
Common Business - Requirements common to most businesses
Accounting
Human Resources
Marketing
Work Effort
Reporting
Document Management
E-Commerce
Others to be
identified
I would like to start with Human Resources. Is anyone interested?
Tom
________________________________
From: Pierre Smits<pierre.sm...@gmail.com>
To: dev@ofbiz.apache.org
Sent: Wednesday, March 14, 2012 5:53 PM
Subject: Re: Rethinking the structure of the OFBiz Applications
Components
Hi Adrian,
Could you list the applications you comment out in your production
implementations? I think that would help creating insight.
Regards,
Pierre
Op 14 maart 2012 18:33 schreef Adrian Crum<
adrian.c...@sandglass-software.com> het volgende:
Understood.
As a service provider, I regularly comment out unused applications and
build hot-deploy components to replace OOTB OFBiz components. I
override
service definitions, redefine entity definitions, etc - all in an
effort to
take what's good in OFBiz, and replace what's not-so-good. I seem to be
doing a lot more of it lately - mostly due to components being added
that
break every other component. At least with a component approach,
that sort
of thing can be isolated and dealt with.
-Adrian
On 3/14/2012 5:22 PM, Jacopo Cappellato wrote:
Thank you Adrian.
Just to clarify that I was not talking about the architecture of the
framework (topic for another day) but only for the layout of the
applications and it is not based on what I think it is best in
general but
instead about what I think it is best to represent what we have
right now:
what we have right now is *one* big application (made of mostly all
the
components under the "applications" folder) that is split into
chunks (the
components) where each chunk is not built to be used alone.
I would be really interested to know from the users of the
"applications"
how many of them are removing (or not deploying) the components
they do not
need in their business.
All in all I am trying to better represent (in a more convenient,
cheaper, easier to maintain way) what we already have, not to
suggest how
the perfect application built on OFBiz should be. The approach that
you are
suggesting on the other hand, that is inspiring, implies a complete
refactoring and redesign (also in terms of features) of the
applications.
Jacopo
On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote:
That approach sounds very monolithic, and I tend to avoid
monoliths.
I gave this subject a lot of thought about a year ago when I was
working
on a vision for a new framework (https://cwiki.apache.org/**
confluence/display/OFBADMIN/**Another+Framework+Vision<https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision>).
In particular, I was trying to devise a way for us to build a new
architecture for OFBiz out of well-defined and self-contained
parts - with
the ultimate goal of using OSGI to connect them all together.
That goal led to only one pattern that seemed to work: Hub-and-spoke.
Hubs can be suspended, replaced, and restarted without too much
disruption
because they affect only the spokes connected to them.
It sounds like what you're proposing is a layered pattern - like a
wall
built up of many bricks, but with an all-covering capstone on top.
I don't have a strong opinion on which approach is best, but I
tend to
favor modularity.
The discussion is worthwhile, and I appreciate you starting it.
-Adrian
On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
In the eraly days of the project, the OFBiz applications have been
designed as independent components to make them more reusable and
because
they were designed to be a set of reusable and generic artifacts,
each of
them based on a specific domain of the data model (order, party,
product
etc...).
They were not intended to be ready to be used out of the box;
they were
not intended to implement complete ERP workflows (mostly all
complete real
World workflows encompass several domains) but rather to provide
some
common artifacts (screens, forms, basic business rules) to
facilitate the
implementation of custom applications.
However over the years, they have been implemented to be used as
being
part of the same big suite of ERP applications: i.e. the building
blocks of
a specific instance of an ERP system.
Some (parts) of them have become "ready to be used" out of the
box (for
certain specific business models) by implementing more specific
workflows
(based on some real World requirements coming from companies):
because of
the fact that there was not a central design and coordination (which
industry/business to implement etc...) and because for the same task
(shipping, receiving etc...) there are thousands of different valid
worflows we have now several workflows in OFBiz that implement
similar
features but in different alternative ways.
It is off topic here to say if this is good (the company user can
choose between a series of choices based on the nature of its
business and
then customize/clean/complete them) or bad (a lot of duplicated
code, the
applications seem to deal with everything but they are not really
really
good for anything): however it is a reality that the applications
are now
more a suite of ERP application (one application) rather than
reusable
generic artifacts that can be plugged together.
In fact the OFBiz Applications are now a set of OFBiz components
that
are strictly interdependent at several layers (data model,
service, ui).
In their current status I believe that it would be better to
merge them
into one big component, the "Apache OFBiz ERP" (or a better name).
The component will contain:
* the complete data model for the OFBiz application
* all the services (Java, Minilang)
* all data
* one web application (merged from the existing ones); even if
initially we could do this in steps and keep them separated as
they are now
but under the same component
* one aggregated and consolidated set of ui labels
Even in one component we will have several mechanisms to
categorize our
artifacts (file names, folders) even if I would suggest to
rethink them
based on new rules (and only if we need the categorization).
We could merge a lot of files (data preparation scripts, screen
definitions, service definitions etc...) to make them more
consistent. We
would also resolve some of the issues with inter-application
links and
navigation.
I am pretty sure that we could end up with less code and easier to
organize and maintain.
It will also be more practical to reuse this component and extend it
from an external hot deploy component: you will have to extend
one webapp
and then reuse from the official component what you like.
This is just the rough ideas and there could be some variants to
it: we
could isolate all the data model and services into one component
and all
the applications (ui, screens, controllers, data prep scripts and
templates) into another one. etc. etc. etc...
It is a lot of work but we are a big community and we like to
keep us
busy.
What do you think?
Jacopo
