My New Priority: Collaboration on Requirements and Designs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

My New Priority: Collaboration on Requirements and Designs

David E. Jones-2

The last major priority that I pushed on was clean ups and  
enhancements to the framework. While there are still some big  
improvements coming along (new authorization approach and more AJAX/
etc stuff come to mind), I think we've made huge progress on that and  
the framework is significantly cleaner and far more helpful when  
writing business applications.

I've mentioned this a little bit and started putting some seed  
material together, and the next high level priority that I'd like to  
work on (and work with others on!) is to add collaboration on  
requirements and designs to our existing excellent collaboration on  
implementation.

What I mean by that is instead of collaborating mostly through the  
code and lower level artifacts I'd like to work with others on higher  
level artifacts including requirements (organized by process from an  
end-user organization perspective) and designs based on those  
requirements, and then use those designs to improve OFBiz. The most  
important improvement that should result from this is that we have  
applications that are designed to support various business activities  
and that better meet the needs of various types of end-users. These  
may be improvements to the existing base "applications", and many will  
work best as "specialpurpose" applications that are based on the base  
applications and that more directly address the needs of certain users.

There are some exciting possibilities for this. One of them that seems  
interesting to lots of people right now is to create an application  
that OFBiz itself will use. Once that happens we can make sure it  
works well for other open source projects (both in and out of the ASF)  
and make using it a no-brainer choice that will not only help the  
world of open source in general, but also be perhaps the best form of  
marketing that OFBiz could ask for as an open source project with no  
real marketing budget.

There are many other types of organizations we could target, and what  
I've started working on to help us collaborate on requirements  
acknowledges this. Some of these organization types will share  
business activities and can share requirements, designs, and  
implementations. Others will have some pretty unique requirements. For  
example there are many things that an open source project does that  
service providers also do (such as manage tasks and issues), but also  
many things that each does that the other does not (open source  
projects don't typically invoice for work done, collect against  
receivables, etc).

One other important aspect of this is documentation. A few people have  
written on the mailing lists and to me personally about this recently.  
My opinion is that this collaboration on requirements will be the  
single most important effort to prepare for a successful documentation  
effort. The requirements themselves (and overlap information with OOTB  
apps and links to designs that are implemented) have some value as  
implicit documentation, and more importantly provide a foundation and  
structure that is consistent with what end-users are looking for and  
will help organize a large volume of information. IMO that is one of  
the biggest problems with documentation efforts to date: it is not  
consistently organized, and it is very tough in general to organize it.

Anyway, here is the main page for what I'm calling the "Universal  
Business Process Library":

http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+Index

The name is based on the concept of the "Universal Data Model" that we  
got from "The Data Model Resource Book, Revised Edition, Volumes 1 and  
2" (and the new Volume 3 is pretty interesting too). The trick is that  
there doesn't seem to be such a thing in existence, at least not in a  
form that is useful to OFBiz. There are lots of standards and other  
efforts that have some great seed material for this, like the UBL and  
OAGIS standards which document information flow between organizations  
at many different points during business processes, but have a focus  
on what is external to an organization instead of one that is  
internal, which is much of what OFBiz provides.

For those who want to get involved, there is a quick introduction to  
UBPL here:

http://docs.ofbiz.org/display/OFBREQDES/UBPL+Introduction

To help people get a quick understanding of the artifacts (documents)  
and process I have in mind for doing these requirements, overlap  
analysis, designs, etc I'm working on a shorter version of the "HEMP"  
book that I've slowly been assembling for the last few years (and more  
formally in the last 1.5 years). I'll send out information on that ASAP.

The most mature high level story for a particular type of organization  
is the "Story of Online Retail Company" which you can find here:

http://docs.ofbiz.org/display/OFBREQDES/Story+of+Online+Retail+Company

That high level story has links to the more detailed stories, many of  
which can be shared with other types of organizations and so they are  
organized separately under the "General Business Process Stories"  
section of the UBPL Index page.


===============================

Sorry for the long email! I know I've also written something similar  
to this before, and there is a reason I'm writing about it again! I'll  
be presenting about this at OSCON in July, and probably also at  
ApacheCon in November, but there is another reason.

Another benefit to this pattern is that if used for projects that  
involve customization of OFBiz it will significantly increase chances  
of success in terms of overall efficiency and also effective  
applicability to the end-user organization.

Helping others do just that is what I have chosen for the next step of  
my career. To pursue that direction I have recently resigned from  
Hotwax Media and returned to being an Independent Consultant. My hope  
is that by doing this I can work with more of you and do so in a way  
that best meets your needs. For more information see my recent blog  
post on the topic (at http://osofbiz.blogspot.com/) and my new web  
site (at http://www.dejc.com/).

My vision for the future is to solve the biggest problem that OFBiz  
has right now (applicability to end-user organizations) and the  
biggest problem most service providers have (successfully tailoring  
OFBiz to the needs of their clients)... which also happens to be the  
biggest opportunity for service providers too.

I look forward to collaborating a lot more with a lot more of you!

-David


Reply | Threaded
Open this post in threaded view
|

Re: My New Priority: Collaboration on Requirements and Designs

Adrian Crum
David E Jones wrote:
> The last major priority that I pushed on was clean ups and enhancements
> to the framework. While there are still some big improvements coming
> along (new authorization approach and more AJAX/etc stuff come to mind),
> I think we've made huge progress on that and the framework is
> significantly cleaner and far more helpful when writing business
> applications.

The new authorization approach has been discussed, but very little work
has been done. Maybe you should finish that priority before starting a
new one.

> What I mean by that is instead of collaborating mostly through the code
> and lower level artifacts I'd like to work with others on higher level
> artifacts including requirements (organized by process from an end-user
> organization perspective) and designs based on those requirements, and
> then use those designs to improve OFBiz. The most important improvement
> that should result from this is that we have applications that are
> designed to support various business activities and that better meet the
> needs of various types of end-users. These may be improvements to the
> existing base "applications", and many will work best as
> "specialpurpose" applications that are based on the base applications
> and that more directly address the needs of certain users.

I would like to be a part of that.

> Helping others do just that is what I have chosen for the next step of
> my career. To pursue that direction I have recently resigned from Hotwax
> Media and returned to being an Independent Consultant.

So, you're back to eating macaroni and cheese? ;-)

-Adrian

Reply | Threaded
Open this post in threaded view
|

Re: My New Priority: Collaboration on Requirements and Designs

Shi Yusen
In reply to this post by David E. Jones-2
Great!

在 2009-06-11四的 04:03 -0600,David E Jones写道:

> The last major priority that I pushed on was clean ups and  
> enhancements to the framework. While there are still some big  
> improvements coming along (new authorization approach and more AJAX/
> etc stuff come to mind), I think we've made huge progress on that and  
> the framework is significantly cleaner and far more helpful when  
> writing business applications.
>
> I've mentioned this a little bit and started putting some seed  
> material together, and the next high level priority that I'd like to  
> work on (and work with others on!) is to add collaboration on  
> requirements and designs to our existing excellent collaboration on  
> implementation.
>
> What I mean by that is instead of collaborating mostly through the  
> code and lower level artifacts I'd like to work with others on higher  
> level artifacts including requirements (organized by process from an  
> end-user organization perspective) and designs based on those  
> requirements, and then use those designs to improve OFBiz. The most  
> important improvement that should result from this is that we have  
> applications that are designed to support various business activities  
> and that better meet the needs of various types of end-users. These  
> may be improvements to the existing base "applications", and many will  
> work best as "specialpurpose" applications that are based on the base  
> applications and that more directly address the needs of certain users.
>
> There are some exciting possibilities for this. One of them that seems  
> interesting to lots of people right now is to create an application  
> that OFBiz itself will use. Once that happens we can make sure it  
> works well for other open source projects (both in and out of the ASF)  
> and make using it a no-brainer choice that will not only help the  
> world of open source in general, but also be perhaps the best form of  
> marketing that OFBiz could ask for as an open source project with no  
> real marketing budget.
>
> There are many other types of organizations we could target, and what  
> I've started working on to help us collaborate on requirements  
> acknowledges this. Some of these organization types will share  
> business activities and can share requirements, designs, and  
> implementations. Others will have some pretty unique requirements. For  
> example there are many things that an open source project does that  
> service providers also do (such as manage tasks and issues), but also  
> many things that each does that the other does not (open source  
> projects don't typically invoice for work done, collect against  
> receivables, etc).
>
> One other important aspect of this is documentation. A few people have  
> written on the mailing lists and to me personally about this recently.  
> My opinion is that this collaboration on requirements will be the  
> single most important effort to prepare for a successful documentation  
> effort. The requirements themselves (and overlap information with OOTB  
> apps and links to designs that are implemented) have some value as  
> implicit documentation, and more importantly provide a foundation and  
> structure that is consistent with what end-users are looking for and  
> will help organize a large volume of information. IMO that is one of  
> the biggest problems with documentation efforts to date: it is not  
> consistently organized, and it is very tough in general to organize it.
>
> Anyway, here is the main page for what I'm calling the "Universal  
> Business Process Library":
>
> http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+Index
>
> The name is based on the concept of the "Universal Data Model" that we  
> got from "The Data Model Resource Book, Revised Edition, Volumes 1 and  
> 2" (and the new Volume 3 is pretty interesting too). The trick is that  
> there doesn't seem to be such a thing in existence, at least not in a  
> form that is useful to OFBiz. There are lots of standards and other  
> efforts that have some great seed material for this, like the UBL and  
> OAGIS standards which document information flow between organizations  
> at many different points during business processes, but have a focus  
> on what is external to an organization instead of one that is  
> internal, which is much of what OFBiz provides.
>
> For those who want to get involved, there is a quick introduction to  
> UBPL here:
>
> http://docs.ofbiz.org/display/OFBREQDES/UBPL+Introduction
>
> To help people get a quick understanding of the artifacts (documents)  
> and process I have in mind for doing these requirements, overlap  
> analysis, designs, etc I'm working on a shorter version of the "HEMP"  
> book that I've slowly been assembling for the last few years (and more  
> formally in the last 1.5 years). I'll send out information on that ASAP.
>
> The most mature high level story for a particular type of organization  
> is the "Story of Online Retail Company" which you can find here:
>
> http://docs.ofbiz.org/display/OFBREQDES/Story+of+Online+Retail+Company
>
> That high level story has links to the more detailed stories, many of  
> which can be shared with other types of organizations and so they are  
> organized separately under the "General Business Process Stories"  
> section of the UBPL Index page.
>
>
> ===============================
>
> Sorry for the long email! I know I've also written something similar  
> to this before, and there is a reason I'm writing about it again! I'll  
> be presenting about this at OSCON in July, and probably also at  
> ApacheCon in November, but there is another reason.
>
> Another benefit to this pattern is that if used for projects that  
> involve customization of OFBiz it will significantly increase chances  
> of success in terms of overall efficiency and also effective  
> applicability to the end-user organization.
>
> Helping others do just that is what I have chosen for the next step of  
> my career. To pursue that direction I have recently resigned from  
> Hotwax Media and returned to being an Independent Consultant. My hope  
> is that by doing this I can work with more of you and do so in a way  
> that best meets your needs. For more information see my recent blog  
> post on the topic (at http://osofbiz.blogspot.com/) and my new web  
> site (at http://www.dejc.com/).
>
> My vision for the future is to solve the biggest problem that OFBiz  
> has right now (applicability to end-user organizations) and the  
> biggest problem most service providers have (successfully tailoring  
> OFBiz to the needs of their clients)... which also happens to be the  
> biggest opportunity for service providers too.
>
> I look forward to collaborating a lot more with a lot more of you!
>
> -David
>
>

Reply | Threaded
Open this post in threaded view
|

Re: My New Priority: Collaboration on Requirements and Designs

David E. Jones-2
In reply to this post by Adrian Crum

On Jun 11, 2009, at 9:33 AM, Adrian Crum wrote:

> David E Jones wrote:
>> The last major priority that I pushed on was clean ups and  
>> enhancements to the framework. While there are still some big  
>> improvements coming along (new authorization approach and more AJAX/
>> etc stuff come to mind), I think we've made huge progress on that  
>> and the framework is significantly cleaner and far more helpful  
>> when writing business applications.
>
> The new authorization approach has been discussed, but very little  
> work has been done. Maybe you should finish that priority before  
> starting a new one.

One must set priorities... are you saying you disagree with the  
priorities as I've stated (ie the requirements gathering to drive  
refinements and new development is more important than the security  
changes)?

I must admit I would like to do the security changes too... but I  
don't think it's as important (not for me and not right now anyway).

>> What I mean by that is instead of collaborating mostly through the  
>> code and lower level artifacts I'd like to work with others on  
>> higher level artifacts including requirements (organized by process  
>> from an end-user organization perspective) and designs based on  
>> those requirements, and then use those designs to improve OFBiz.  
>> The most important improvement that should result from this is that  
>> we have applications that are designed to support various business  
>> activities and that better meet the needs of various types of end-
>> users. These may be improvements to the existing base  
>> "applications", and many will work best as "specialpurpose"  
>> applications that are based on the base applications and that more  
>> directly address the needs of certain users.
>
> I would like to be a part of that.

Excellent!

>> Helping others do just that is what I have chosen for the next step  
>> of my career. To pursue that direction I have recently resigned  
>> from Hotwax Media and returned to being an Independent Consultant.
>
> So, you're back to eating macaroni and cheese? ;-)

I'm more of a soaked grain kind of guy than a mac & cheese fellow. I  
gave that up in college... though it was more ramen noodles for me. ;)

Actually, it's more like I'm stepping away from investments and  
getting back to earning some money. It's really nice to be able to  
work for a week and survive off that for the rest of the month, and  
work on more interesting things that often have more impact too. Not  
that I'm there yet... I need to shed a couple of other "investments"  
first. :(

Right now I wish that I had invested in AR-15 rifles over the last few  
years instead of real estate and software consulting... I could have a  
few hundred grand sitting in the bank (thanks to John Stewart on his  
Daily Show for pointing out that missed opportunity!). ;)

-David

Reply | Threaded
Open this post in threaded view
|

Re: My New Priority: Collaboration on Requirements and Designs

Adrian Crum-2
In reply to this post by David E. Jones-2

--- On Fri, 6/12/09, David E Jones <[hidden email]> wrote:
> One must set priorities... are you saying you disagree with
> the priorities as I've stated (ie the requirements gathering
> to drive refinements and new development is more important
> than the security changes)?

I guess so. It would be nice to get something on that low level finalized before we start building out more applications (that would have to be refactored if it was the other way around).

-Adrian



     
Reply | Threaded
Open this post in threaded view
|

Re: My New Priority: Collaboration on Requirements and Designs

David E. Jones-2
In reply to this post by David E. Jones-2

As I mentioned in the email below I've been working on the lightweight  
version of this analysis and design process, the one I propose to use  
for the UBPL effort.

It is now available here (link at the bottom of the page):

http://www.dejc.com/home/HEMP.html

Comments and feedback are welcome on this! I imagine this "HEMP light"  
document and the ones that follow will go through a goodly number of  
revisions. :)

-David


On Jun 11, 2009, at 4:03 AM, David E Jones wrote:

>
> The last major priority that I pushed on was clean ups and  
> enhancements to the framework. While there are still some big  
> improvements coming along (new authorization approach and more AJAX/
> etc stuff come to mind), I think we've made huge progress on that  
> and the framework is significantly cleaner and far more helpful when  
> writing business applications.
>
> I've mentioned this a little bit and started putting some seed  
> material together, and the next high level priority that I'd like to  
> work on (and work with others on!) is to add collaboration on  
> requirements and designs to our existing excellent collaboration on  
> implementation.
>
> What I mean by that is instead of collaborating mostly through the  
> code and lower level artifacts I'd like to work with others on  
> higher level artifacts including requirements (organized by process  
> from an end-user organization perspective) and designs based on  
> those requirements, and then use those designs to improve OFBiz. The  
> most important improvement that should result from this is that we  
> have applications that are designed to support various business  
> activities and that better meet the needs of various types of end-
> users. These may be improvements to the existing base  
> "applications", and many will work best as "specialpurpose"  
> applications that are based on the base applications and that more  
> directly address the needs of certain users.
>
> There are some exciting possibilities for this. One of them that  
> seems interesting to lots of people right now is to create an  
> application that OFBiz itself will use. Once that happens we can  
> make sure it works well for other open source projects (both in and  
> out of the ASF) and make using it a no-brainer choice that will not  
> only help the world of open source in general, but also be perhaps  
> the best form of marketing that OFBiz could ask for as an open  
> source project with no real marketing budget.
>
> There are many other types of organizations we could target, and  
> what I've started working on to help us collaborate on requirements  
> acknowledges this. Some of these organization types will share  
> business activities and can share requirements, designs, and  
> implementations. Others will have some pretty unique requirements.  
> For example there are many things that an open source project does  
> that service providers also do (such as manage tasks and issues),  
> but also many things that each does that the other does not (open  
> source projects don't typically invoice for work done, collect  
> against receivables, etc).
>
> One other important aspect of this is documentation. A few people  
> have written on the mailing lists and to me personally about this  
> recently. My opinion is that this collaboration on requirements will  
> be the single most important effort to prepare for a successful  
> documentation effort. The requirements themselves (and overlap  
> information with OOTB apps and links to designs that are  
> implemented) have some value as implicit documentation, and more  
> importantly provide a foundation and structure that is consistent  
> with what end-users are looking for and will help organize a large  
> volume of information. IMO that is one of the biggest problems with  
> documentation efforts to date: it is not consistently organized, and  
> it is very tough in general to organize it.
>
> Anyway, here is the main page for what I'm calling the "Universal  
> Business Process Library":
>
> http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+Index
>
> The name is based on the concept of the "Universal Data Model" that  
> we got from "The Data Model Resource Book, Revised Edition, Volumes  
> 1 and 2" (and the new Volume 3 is pretty interesting too). The trick  
> is that there doesn't seem to be such a thing in existence, at least  
> not in a form that is useful to OFBiz. There are lots of standards  
> and other efforts that have some great seed material for this, like  
> the UBL and OAGIS standards which document information flow between  
> organizations at many different points during business processes,  
> but have a focus on what is external to an organization instead of  
> one that is internal, which is much of what OFBiz provides.
>
> For those who want to get involved, there is a quick introduction to  
> UBPL here:
>
> http://docs.ofbiz.org/display/OFBREQDES/UBPL+Introduction
>
> To help people get a quick understanding of the artifacts  
> (documents) and process I have in mind for doing these requirements,  
> overlap analysis, designs, etc I'm working on a shorter version of  
> the "HEMP" book that I've slowly been assembling for the last few  
> years (and more formally in the last 1.5 years). I'll send out  
> information on that ASAP.
>
> The most mature high level story for a particular type of  
> organization is the "Story of Online Retail Company" which you can  
> find here:
>
> http://docs.ofbiz.org/display/OFBREQDES/Story+of+Online+Retail+Company
>
> That high level story has links to the more detailed stories, many  
> of which can be shared with other types of organizations and so they  
> are organized separately under the "General Business Process  
> Stories" section of the UBPL Index page.
>
>
> ===============================
>
> Sorry for the long email! I know I've also written something similar  
> to this before, and there is a reason I'm writing about it again!  
> I'll be presenting about this at OSCON in July, and probably also at  
> ApacheCon in November, but there is another reason.
>
> Another benefit to this pattern is that if used for projects that  
> involve customization of OFBiz it will significantly increase  
> chances of success in terms of overall efficiency and also effective  
> applicability to the end-user organization.
>
> Helping others do just that is what I have chosen for the next step  
> of my career. To pursue that direction I have recently resigned from  
> Hotwax Media and returned to being an Independent Consultant. My  
> hope is that by doing this I can work with more of you and do so in  
> a way that best meets your needs. For more information see my recent  
> blog post on the topic (at http://osofbiz.blogspot.com/) and my new  
> web site (at http://www.dejc.com/).
>
> My vision for the future is to solve the biggest problem that OFBiz  
> has right now (applicability to end-user organizations) and the  
> biggest problem most service providers have (successfully tailoring  
> OFBiz to the needs of their clients)... which also happens to be the  
> biggest opportunity for service providers too.
>
> I look forward to collaborating a lot more with a lot more of you!
>
> -David
>
>

Reply | Threaded
Open this post in threaded view
|

Re: My New Priority: Collaboration on Requirements and Designs

BJ Freeman
In reply to this post by David E. Jones-2
this probably sound off the wall, but i think a good starting point for
all businesses is a Business plan.
I adopted this as my primary model for creating other Business
processes, based on the type of business.


David E Jones sent the following on 6/15/2009 4:20 AM:

>
> As I mentioned in the email below I've been working on the lightweight
> version of this analysis and design process, the one I propose to use
> for the UBPL effort.
>
> It is now available here (link at the bottom of the page):
>
> http://www.dejc.com/home/HEMP.html
>
> Comments and feedback are welcome on this! I imagine this "HEMP light"
> document and the ones that follow will go through a goodly number of
> revisions. :)
>
> -David
>
>
> On Jun 11, 2009, at 4:03 AM, David E Jones wrote:
>
>>
>> The last major priority that I pushed on was clean ups and
>> enhancements to the framework. While there are still some big
>> improvements coming along (new authorization approach and more
>> AJAX/etc stuff come to mind), I think we've made huge progress on that
>> and the framework is significantly cleaner and far more helpful when
>> writing business applications.
>>
>> I've mentioned this a little bit and started putting some seed
>> material together, and the next high level priority that I'd like to
>> work on (and work with others on!) is to add collaboration on
>> requirements and designs to our existing excellent collaboration on
>> implementation.
>>
>> What I mean by that is instead of collaborating mostly through the
>> code and lower level artifacts I'd like to work with others on higher
>> level artifacts including requirements (organized by process from an
>> end-user organization perspective) and designs based on those
>> requirements, and then use those designs to improve OFBiz. The most
>> important improvement that should result from this is that we have
>> applications that are designed to support various business activities
>> and that better meet the needs of various types of end-users. These
>> may be improvements to the existing base "applications", and many will
>> work best as "specialpurpose" applications that are based on the base
>> applications and that more directly address the needs of certain users.
>>
>> There are some exciting possibilities for this. One of them that seems
>> interesting to lots of people right now is to create an application
>> that OFBiz itself will use. Once that happens we can make sure it
>> works well for other open source projects (both in and out of the ASF)
>> and make using it a no-brainer choice that will not only help the
>> world of open source in general, but also be perhaps the best form of
>> marketing that OFBiz could ask for as an open source project with no
>> real marketing budget.
>>
>> There are many other types of organizations we could target, and what
>> I've started working on to help us collaborate on requirements
>> acknowledges this. Some of these organization types will share
>> business activities and can share requirements, designs, and
>> implementations. Others will have some pretty unique requirements. For
>> example there are many things that an open source project does that
>> service providers also do (such as manage tasks and issues), but also
>> many things that each does that the other does not (open source
>> projects don't typically invoice for work done, collect against
>> receivables, etc).
>>
>> One other important aspect of this is documentation. A few people have
>> written on the mailing lists and to me personally about this recently.
>> My opinion is that this collaboration on requirements will be the
>> single most important effort to prepare for a successful documentation
>> effort. The requirements themselves (and overlap information with OOTB
>> apps and links to designs that are implemented) have some value as
>> implicit documentation, and more importantly provide a foundation and
>> structure that is consistent with what end-users are looking for and
>> will help organize a large volume of information. IMO that is one of
>> the biggest problems with documentation efforts to date: it is not
>> consistently organized, and it is very tough in general to organize it.
>>
>> Anyway, here is the main page for what I'm calling the "Universal
>> Business Process Library":
>>
>> http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+Index
>>
>>
>> The name is based on the concept of the "Universal Data Model" that we
>> got from "The Data Model Resource Book, Revised Edition, Volumes 1 and
>> 2" (and the new Volume 3 is pretty interesting too). The trick is that
>> there doesn't seem to be such a thing in existence, at least not in a
>> form that is useful to OFBiz. There are lots of standards and other
>> efforts that have some great seed material for this, like the UBL and
>> OAGIS standards which document information flow between organizations
>> at many different points during business processes, but have a focus
>> on what is external to an organization instead of one that is
>> internal, which is much of what OFBiz provides.
>>
>> For those who want to get involved, there is a quick introduction to
>> UBPL here:
>>
>> http://docs.ofbiz.org/display/OFBREQDES/UBPL+Introduction
>>
>> To help people get a quick understanding of the artifacts (documents)
>> and process I have in mind for doing these requirements, overlap
>> analysis, designs, etc I'm working on a shorter version of the "HEMP"
>> book that I've slowly been assembling for the last few years (and more
>> formally in the last 1.5 years). I'll send out information on that ASAP.
>>
>> The most mature high level story for a particular type of organization
>> is the "Story of Online Retail Company" which you can find here:
>>
>> http://docs.ofbiz.org/display/OFBREQDES/Story+of+Online+Retail+Company
>>
>> That high level story has links to the more detailed stories, many of
>> which can be shared with other types of organizations and so they are
>> organized separately under the "General Business Process Stories"
>> section of the UBPL Index page.
>>
>>
>> ===============================
>>
>> Sorry for the long email! I know I've also written something similar
>> to this before, and there is a reason I'm writing about it again! I'll
>> be presenting about this at OSCON in July, and probably also at
>> ApacheCon in November, but there is another reason.
>>
>> Another benefit to this pattern is that if used for projects that
>> involve customization of OFBiz it will significantly increase chances
>> of success in terms of overall efficiency and also effective
>> applicability to the end-user organization.
>>
>> Helping others do just that is what I have chosen for the next step of
>> my career. To pursue that direction I have recently resigned from
>> Hotwax Media and returned to being an Independent Consultant. My hope
>> is that by doing this I can work with more of you and do so in a way
>> that best meets your needs. For more information see my recent blog
>> post on the topic (at http://osofbiz.blogspot.com/) and my new web
>> site (at http://www.dejc.com/).
>>
>> My vision for the future is to solve the biggest problem that OFBiz
>> has right now (applicability to end-user organizations) and the
>> biggest problem most service providers have (successfully tailoring
>> OFBiz to the needs of their clients)... which also happens to be the
>> biggest opportunity for service providers too.
>>
>> I look forward to collaborating a lot more with a lot more of you!
>>
>> -David
>>
>>
>
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.