Please consider creating a web application like PI Vision Admin, PI Web API Search, PI Manual Logger for Web, and the various integrators, but for PI System Explorer (PSE, PI AF). I would prefer this to the client-server design now. It would make version management, software dependency management, upgrading, firewall/network-services management, etc. easier. This would obviate the need to re-package the OSIsoft installers in whatever software package management software an organization uses. Another solution would be to use the Windows 10 application store. However, that wouldn't mesh well with using Cloud IaaS services. OSIsoft could even offer this new PSE Web as a PaaS: gear, Juju charm, Docker container, Amazon image, whatever.

Originally posted on PI Square at https://pisquare.osisoft.com/ideas/5538-easily-deploying-and-maintaining-af-objects-in-multiple-remote-af-databases

Today, one of the method that can be used to selectively reconcile object changes (including templates, analyses, UOM, etc.) between source and destination servers is using Excel (in order to keep track of object changes and/or object deletions). However, it is very time-consuming and prone to errors.
 
Inspired in the current project I am working on (containing a central AF server and remote AF servers), it would be great to have a tool that allowed us to deploy and maintain all types of AF objects in a selective way in multiple remote AF servers.
 
Here is a use case:
 
The user selects the desired source objects (templates, elements, analyses, enumerations, UOMs, etc.) and export (or "publish") them to several destinations, at once, after of the press of a button (instead of “live” sync). The user selects what to be exported or synchronized to each destination, and not necessarily the same group of objects would be exported/sync to all destinations: each destination may contain different set of elements and templates.The synchronization would support name changes, object additions and deletions (similar to what is available in PI System Connector today)The user should be warned if he tries to export an element that depends on an enumeration or UOM () that is not included in the object set being exported.The user should be optionally warned about the attributes, analyses, etc. that will be deleted from the destination databases, if the corresponding ones have been deleted from the source templates or elements.The user should be able reconcile tag name changes: if the tag name convention is changed in the source attribute set with auto-tag creation, the tags created at the destination should be renamed as per new substitution parameters string.User should be able to save/load different export scenarios. 
() You may ask: why not export the entire UOM? The answer is because the source server may be a development server and may contain UOMs that were added for other type of industries, which would be irrelevant in some production environments.

A few minor improvements to the search and filtering capabilities of the management tab could save time when doing backfills at scale - for example after transferring several elements from a development server.  If possible the following search capabilities could be very useful:
-Improve search by template: Currently when searching by template every analysis will be listed and in alphabetical order by analysis - not template name which makes it difficult to search. It could be helpful if it were possible to choose one template and every analysis associated with that template would be included.  At the very least, adjust the ordering of the drop-down so that it is in alphabetical order by template
-Improve Element search: Include or allow for search of child Elements as part of Element search

When the PI Analysis service determines an Analysis should be Suspended, it should also set any output Attributes to be Excluded. As the Analysis is Suspended, it will not output any results and if it has always been Suspended, the output Tags will never get created. Excluding the output Attributes will keep the Element looking clean and also allow dependent Analyses to go into a Suspended state instead of throwing an error when they can't find the Tags. Similarly it will prevent other applications (OSIsoft and third parties) from querying the Attributes and also throwing errors, causing performance issues.

Automatically suspended Analyses when the inputs are excluded was an extremely useful feature and has made supporting and maintaining an AF database easier. Automatically excluding the output attributes is a natural progression of this feature and will make AF database even more easier to maintain.