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 |
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 > > |
Free forum by Nabble | Edit this page |