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

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