The eLandings team has provided web pages to export and import landing and production reports. We encourage third-party developers to use these methods while learning how to work with eLandings XML data structures. It may also serve as a temporary backup strategy if or when third-party applications become out of date with their eLandings XML schema definition. Although not recommended, third-party developers may choose to build applications that revolve sole around these web pages without making use of the public web services. This approach attempts to shifts work from the third-party developer to the user of the application and to eLandings developers. Such solutions may be cheaper to implement in the short term but more costly to maintain over time. It is predicted that end users will be less satisfied with third-party applications built on this philosophy.
If third-party developers opt for this approach they can expect the following:
- Inability to create all desired features requested by the user group
t is expected that third-party developers who opt to build their solution solely around eLandings web pages, will be unable to create all the desired features requested by their user group.
The choice to build third-party solutions solely around eLandings web pages results in shifting work responsibility from the third-party programming staff to the eLandings programming staff. Third-party developers are in effect saying "I want eLandings developers to build and maintain the interfaces by which my users will import and export eLandings data." Predictably, third-party developers who make this choice sacrifice control of those interfaces and the timeline for the implementation of changes to those interfaces.
The eLandings team has a small staff of programmers with limited time and resources. The eLandings project is under active development with a very long list of new systems, enhancements, improvements, refactoring, general maintenance, and bug fixes. The eLandings programming staff time is fully allocated. Due to the large workload and small staff, eLandings programmers may be unable to implement reasonable third-party developer requests in as timely a manner.
Any request made by third-party developers of the eLandings programming staff must be reviewed and prioritized within the existing workload, prior to work being done. As with all eLandings programmer tasks, third-party modification requests for the eLandings web pages, fall into the following categories:
The requested change cannot be done
The requested change would negatively impact other users
The requested change would take a very long time to implement and would have very little positive impact
The requested change would have positively impact but has a lower priority than other higher priority issues.
The requested change would have a large positive impact and can be quickly implemented
The requested change would have the highest positive impact of any potential development task in eLandings
By relying on eLandings programmers to provide the import and export interfaces, third-party developers are choosing to have other people prioritize the third-party requests within a much larger list of unrelated pressing issues that will impact a much larger group of unrelated users. Predictable, the eLandings team will not come to the same conclusions of priority and time allocation that third-party developers might like. For additional information see: <ADD LINK TO "eLandings Team Structure and Request Handling" below>
- Inability to handle a large number of reports efficiently
- Requiring the users to do more work than a comparable system built using the public web services