Recently, there was a discussion thread within the vCampus community regarding whether a facelift is needed for our beloved PI ProcessBook.
In the ensuing discussion, there were several comments on desired changes to PI ProcessBook functionality (which is not the same as a visual update in any way). Part of that commentary was an expressed frustration with not knowing how to get enhancement requests addressed. I wanted to take some time to be frank about proposed changes to PI ProcessBook as we know and love it.
It is no great secret that PI ProcessBook has been evolving from the original code base for about 15 years now. It is also no secret that the technology on which it is based is rather dated. Furthermore, as features have been added over the years, the code has grown more complex and difficult to maintain. As a result, the last few releases of PI ProcessBook have featured new capabilities that have added on to the existing features rather than re-writing them. One reason for this approach has been that we are ever sensitive to the investment existing users have made in PI ProcessBook content and we have no intention of releasing a new version that breaks their existing displays, to the best of our ability to prevent that. (I recently received anecdotal evidence that displays created 10 years ago or more continue to be used in PI ProcessBook today--not a bad testimony to the product's overall stability.)
The effect of this conservative approach is that we don't intend to make deep architectural changes to PI ProcessBook. So, things like changing the way symbols are drawn or rendered are not going to happen.
That doesn't mean there isn't anything useful to add to the existing capabilities.
Of those requested changes that do not represent deep changes to how the product works, there is a rather long list of things that could be done. Requests for change are weighed against one another as well as other factors. For example, those cross-product capabilities of the PI System that the company is focused on may take priority over smaller requests for changes that only affect PI ProcessBook. Problems customers have in making displays work the way they were intended (and for which there isn't any remedy) often take precendence over requests that would be handy but can still be done in some fashion. New versions of Microsoft technologies that have an impact on PI ProcessBook (e.g., a new operating system, new versions of .NET, etc.) need to be tested for compatibility and any issues considered. Capabilities that allow PI ProcessBook to be useful in newer markets (e.g., customers outside of North America) may also get precendence, if that is strategic for the company.
Whenever we plan a new release of PI ProcessBook, we look at the major new capabilities we plan to provide and then consider which of the outstanding requests would fit in with the planned work. Sometimes, priorities change between the initial planning and final release of a new version. Our PI System Roadmap, available on the Technical Support web site, characterizes those enhancements to which we've committed for an upcoming release and, often, the additional changes we've considered adding (but which may change). We don't list every single change we are planning (on the Roadmap) because that information can change more quickly as particular requests are investigated (for example), and keeping such a list truly up-to-date is difficult at best. We do try to mark the planned items when a release is started, but the work may get delayed for many reasons (there is a technical barrier, the developers don't understand the desired functionality well enough, another item with higher priority intrudes, there are conflicting requests from different customers, etc.). This process isn't designed to frustrate our customers, but it is a reality in a product-development company that serves many industries that have a variety of similar yet unique requirements for displaying time series data in a graphical fashion.
Hopefully, I've been clear about the sort of decison-making we go through at OSIsoft. I do understand that it can be very frustrating not to know when your particular request will get addressed, for sure, but that doesn't mean we aren't trying to provide new and useful features to PI ProcessBook.