As mentioned throughout this report, the Prototype was developed to meet specified service objectives within accepted constraints defined by the scope of the project. As such, the Prototype exhibited limitations that would not be evident or even desirable in a fully functioning production system. Table 8 summarizes some of the Prototype characteristics and constraints and compares them to what would need to be addressed in a production-quality system.

Table 8. Comparison of Prototype Features to Production Requirements

Category / Feature	Status in Prototype	Status in Production System Infrastructure
Status in Production System Infrastructure
Incorporate full application functionality	Prototype included functionality within applications that satisfied its scope. For example, it allowed viewing of possible errors on parcel transfers, but not error correction.	Full functionality of all applications would be required. For example, would need capability to correct possible errors on parcel transfer, not just view them.
Reliability of access	Handled on a case-by-case basis within Prototype.	Would need to address issues of providing reliable service while running important business tasks over the public Internet.
Financial Processing	Outside the scope of the Prototype.	Necessary part of some transactions.
Email Functionality	Not available in the Prototype.	Would include enhanced email features such as automatic email notification when proposed entries have been addressed.
Identity Management
Account management	The Prototype used centralized management of user identities and role-based assignments and did not address ongoing issues of people leaving, new arrivals, and transfers.	Would require a combination of centralized and decentralized management of identities and role-based assignments, plus a policy, process, and mechanism for handling changes.
Data Considerations
One Data Set Shared by All Users	Did not address policy issues that might arise such as how to handle dog license transfers when each municipality can see data from others. Prototype had no built-in mechanism to ensure a user could register dogs only in her own municipality.	Programming constraints need to be developed that reflect all business rules and policy issues.
Data integration from multiple sources	One-time data integration from 3 sources, "cleansed" enough to support Prototype applications.	Would need to integrate from additional data sources, perform more high-quality data cleansing, and provide for ongoing data management and maintenance.
Complete data sets	Prototype used a partial data set that was adequate for its scope.	Would require complete and up-to-date data sets.
Ability to load and unload bulk data in a batch mode	Not provided in the Prototype.	Would include functionality to upload and download batches of data to and from applications such as the Contact Repository.
Data integration into applications and systems outside the Prototype	Not addressed in Prototype, which was developed as self-contained within scope of the Prototype applications.	Required component to handle key transactions such as licensing fees, state and local fees, that would be integrated with financial systems.
Information Policies
Governance	The informal Advisory Committee provided governance for development, testing, and evaluation of the Prototype.	A formal intergovernmental structure would set direction, adopt policies, etc.
Shared code	Not addressed in Prototype, which had separate applications running in the Prototype.	Would develop ways to enhance re-use of code and collapse common or similar web development tasks into one.
Usability
Ease of Use	Some usability issues could be tolerated within Prototype environment.	User interface would be refined through successive user acceptance testing, field tests, and focus groups until all usability issues are addressed
Context-sensitive help	Prototype provided only general help screens.	Help information would be specific to functions and events within the system so users would find help where and when they need it.
Personalization of resources section based on User’s Role	Prototype provided a generic Resources sections that was available and identical for all users.	Would provide ability for individual users to customize their Resources section based on their role and interests.