PAIL Discussion - 2016 ASABE AIM

Development Philosophy

The PAIL project seeks to develop a common language that enables integration of all the disparate sources of water management technology. Working with a large variety of technology requires more expertise than any one discipline or entity so a collaborative approach was required. In “The Cathedral and the Bazar” (Raymond, 2001), Raymond describes two philosophies of software development.  The cathedral is essentially the traditional academic approach. A group of experts and thinkers apply their substantial knowledge of a problem, test it, and deliver it to the expected consumers via publications, seminars, and classes. This approach has its benefits. The cathedral can produce solutions that are cohesive, clearly scoped, and well founded in research. The disadvantage is that these solutions do not always accommodate the practical realities that practitioners must live with. This problem is usually emerges from a desire to avoid complexities that would complicate an otherwise simple conceptual framework or when the complexities are caused by issues unrelated to the application domain. To the practitioners, those omissions are often perceived as a lack of understanding about real world conditions and leads to the “Ivory Tower” perception of academic solutions.

The other method Raymond describes is the Bazaar. This is an open approach where anyone can participate (within reason). Participants are expected to contribute and the major impacts come from those that do most of the work. The Bazaar approach is messy, slow, and often contentious. However, the Bazaar has one significant advantage: the result is a product that is what the practitioners need. The nature of participatory development means that, by the end of the development cycle, practitioners have already adopted the new system. This contrast with the Cathedral approach where motivating adoption is the critical and last step in the development process.

PAIL’s development has followed the Bazaar model. Any corporation or individual can join AgGateway and participate in the development. In fact, the early work of PAIL was primarily focused on recruiting participants. The development process has gone on for nearly three years and by the time the standard is released, there will already be several companies that have adopted the early release version. Those companies are the same ones that helped develop PAIL.

A Vehicle for Research

A final goal of PAIL is specifically related to research. Many DSS tools are developed by researchers with the intention of providing producers with an easier way to implement complicated but robust management practices. These tools incorporate advanced analytical methods and often include field validation that demonstrates their potential for resource conservation, improved efficiency, ore greater profitability. The tool itself, however, is written by a graduate student (who’s field of study is not interface design or software engineering). When the student graduates, development stops and does not continue unless the principal investigators can find additional funding. Often times the DSS will “sit on a shelf collecting dust”.

Grant driven research is not a feasible framework for maintaining applied, production oriented software. That type of tool requires customer support, continual debugging, and a commitment to evolving the software as customer’s needs evolve. Commercial development is geared towards those needs and software companies are successful because they provide those services effectively.

Standardized interoperability provides a means for researchers to deliver research products, in the form of DSS, without the burdens associated with maintenance and customer support. The DSS tools are written to interact with the interfaces or data formats defined by the PAIL standard. This frees the researchers (and the graduate students) from the need to build a “user friendly” interface. Instead, companies can integrate the DSS into their products and focus on providing the user interface and customer support that they are successful at providing. Thus, the PAIL standard is a means to deliver the benefits of research to growers without the burden of continually finding funding to support maintenance.

There is one other research-oriented aspect that is an indirect consequence of the Bazaar model of development. The companies that drive PAILs development are focused on providing services that are needed now or will be in the near future. To be useful, the standard must be relevant to current practices. Research, on the other hand, is focused on developing new methods and these methods may require data or concepts no in use by industry. Because the standard is focused on current practice, it may not have sufficient constructs to express the new methods. Significant effort was mad to develop a standard that is generic enough to avoid these conflicts but no standard can account for every eventuality. When researchers encounter a situation where a new method cannot be expressed in PAIL, this is an indirect indication of a significant incompatibility with current practices. Such conflicts will motivate researcher to educate the industry and motivate change in practice, or a change in the PAIL standard itself.

3) Insert [ Lightning bolt or cognitive flatulence? THAT is the question... ] here.

asd

4) Lessons from ISO11783 (Andres)

• Value of schema
• Value of data dictionary
• Reminder of why we aren't using it
  • Different scope (farther from the hardware)
  • Geometry incompatible
  • More business process, rather than machine,  oriented

5) Ease of Integration (Dan)

• From a grower's point of view, they can implement this as they need to.
• From an FMIS or other integrator's point of view, this replaces multiple point-to-point integrations with one single FMIS-to-PAIL format integration.

Development Philosophy

The PAIL project seeks to develop a common language that enables integration of all the disparate sources of water management technology. Working with a large variety of technology requires more expertise than any one discipline or entity so a collaborative approach was required. In “The Cathedral and the Bazar” (Raymond, 2001), Raymond describes two philosophies of software development.  The cathedral is essentially the traditional academic approach. A group of experts and thinkers apply their substantial knowledge of a problem, test it, and deliver it to the expected consumers via publications, seminars, and classes. This approach has its benefits. The cathedral can produce solutions that are cohesive, clearly scoped, and well founded in research. The disadvantage is that these solutions do not always accommodate the practical realities that practitioners must live with. This problem is usually emerges from a desire to avoid complexities that would complicate an otherwise simple conceptual framework or when the complexities are caused by issues unrelated to the application domain. To the practitioners, those omissions are often perceived as a lack of understanding about real world conditions and leads to the “Ivory Tower” perception of academic solutions.

The other method Raymond describes is the Bazaar. This is an open approach where anyone can participate (within reason). Participants are expected to contribute and the major impacts come from those that do most of the work. The Bazaar approach is messy, slow, and often contentious. However, the Bazaar has one significant advantage: the result is a product that is what the practitioners need. The nature of participatory development means that, by the end of the development cycle, practitioners have already adopted the new system. This contrast with the Cathedral approach where motivating adoption is the critical and last step in the development process.

PAIL’s development has followed the Bazaar model. Any corporation or individual can join AgGateway and participate in the development. In fact, the early work of PAIL was primarily focused on recruiting participants. The development process has gone on for nearly three years and by the time the standard is released, there will already be several companies that have adopted the early release version. Those companies are the same ones that helped develop PAIL.

A Vehicle for Research

A final goal of PAIL is specifically related to research. Many DSS tools are developed by researchers with the intention of providing producers with an easier way to implement complicated but robust management practices. These tools incorporate advanced analytical methods and often include field validation that demonstrates their potential for resource conservation, improved efficiency, ore greater profitability. The tool itself, however, is written by a graduate student (who’s field of study is not interface design or software engineering). When the student graduates, development stops and does not continue unless the principal investigators can find additional funding. Often times the DSS will “sit on a shelf collecting dust”.

Grant driven research is not a feasible framework for maintaining applied, production oriented software. That type of tool requires customer support, continual debugging, and a commitment to evolving the software as customer’s needs evolve. Commercial development is geared towards those needs and software companies are successful because they provide those services effectively.

Standardized interoperability provides a means for researchers to deliver research products, in the form of DSS, without the burdens associated with maintenance and customer support. The DSS tools are written to interact with the interfaces or data formats defined by the PAIL standard. This frees the researchers (and the graduate students) from the need to build a “user friendly” interface. Instead, companies can integrate the DSS into their products and focus on providing the user interface and customer support that they are successful at providing. Thus, the PAIL standard is a means to deliver the benefits of research to growers without the burden of continually finding funding to support maintenance.

There is one other research-oriented aspect that is an indirect consequence of the Bazaar model of development. The companies that drive PAILs development are focused on providing services that are needed now or will be in the near future. To be useful, the standard must be relevant to current practices. Research, on the other hand, is focused on developing new methods and these methods may require data or concepts no in use by industry. Because the standard is focused on current practice, it may not have sufficient constructs to express the new methods. Significant effort was mad to develop a standard that is generic enough to avoid these conflicts but no standard can account for every eventuality. When researchers encounter a situation where a new method cannot be expressed in PAIL, this is an indirect indication of a significant incompatibility with current practices. Such conflicts will motivate researcher to educate the industry and motivate change in practice, or a change in the PAIL standard itself.