Revised ConservationSpace Build Call for Qualifications.docx

ConservationSpace Build Call for Qualifications

Introduction The cultural heritage conservation community realized many years ago that a digital solution for managing documents could increase access, expand research opportunities, support workflow procedures, and reduce the loss of important records. Conservation documents typically include reports; B&W and color photographic prints, photographic negatives, photographic transparencies, digital images; x-radiographs; data from scientific analyses; correspondence; and hand-written notes. It once was the case that virtually all documents were either paper or film-based and could be easily managed easily using appropriate filing procedures. The quantity and diversity of documents generated in the digital age, however, has made the process extraordinarily complex. In response to this problem, many institutions and private conservators have devised procedures and software applications to manage documents but with little concern for compatibility or long-term preservation. Several years ago, the Andrew Mellon Foundation recognized the need for a coordinated effort to address the rapidly growing problem in the cultural community. Their efforts resulted in a project that is now known as ConservationSpace. (www.ConservationSpace.org).

Presently, the National Gallery of Art, joined by the Courtauld Institute of Art, the Denver Art Museum, the Indianapolis Museum of Art, the Metropolitan Museum of Art, National Gallery of Denmark, and Yale University in an international partnership, is undertaking to hire a developer to implement an open-source software application that serves the needs of the conservation community, to be known as ConservationSpace.

In anticipation of release of a formal request for proposals about September 2012, the project has developed this Call for Qualifications, to explain the project to the development community, engender interest, and uncover weaknesses or oversights in the approach that might jeopardize project success.

Project Goals and Objectives To achieve this vision, we intend to develop an open-source software application that addresses a reasonable set of high priority conservation workflows. The community process to-date has identified workflows in the following areas as high priority for most conservators:

Priority 1

· Exam (Single Object)

· Exam (Multiple Objects)

· Treatment

Priority 2

· Managing and Preserving Documents

Priority 3

· Exhibition

· Photography

· Analysis

· Research

The Partners have elected to include in Release 1.0 the Priority 1 and Priority 2 business processes as well as some documents used for the Priority 3 item, Exhibition. Owing to the diversity and complexity of exhibition management at different locations, no attempt will be made at this time to address the exhibition business process. This functionality will form the core of the first release of ConservationSpace, supporting conservators in their most important activities, through data and record management, search and retrieval of previous work, automated workflow, imaging, and reporting.

Phased Development Approach The development of ConservationSpace was envisioned as a project of three phases, a planning and requirements-gathering phase, a phase for the development of an initial release hosted at a central location, and a phase for installing an extended release at each of the Partners.

Planning and Requirements. In the first phase, currently under way, we are working with the Partners to refine and clarify the requirements and to develop top-level system design guidance for the developer. In this phase we are formally analyzing the operational context of the system to produce an ‘Enterprise Blueprint,’ (defined more completely in the Appendix) holding two rounds of Partner workshops, performing technology trade studies and developing solicitation materials. The end result of this phase will be the release of a Request for Proposals about September 2012 and the selection of a developer about December 2012.

Release 1.0, Hosted. Release 1.0 of the application will allow the most important functionality to be demonstrated to the Partners. Starting from the Enterprise Blueprint, the vendor will develop system architecture, data modeling, application design, software development, refinement, testing, and documentation of the ConservationSpace Enterprise Solution. It is anticipated that this will be done iteratively in a manner that engages the project Partners to utilize their depth and breadth of expertise in the practice of conservation. The vendor will package and document the solution and then install, configure, maintain and provide technical support to a single copy of the software, hosted at a mutually agreed location. Release 1.0 will be utilized by the partner institutions to evaluate the design, usability, performance, and overall effectiveness of the solution. This phase is estimated to take between 6 and 12 months.

The Partners have discussed, with the funder, the possibility of applying for additional funding that will be used to improve and expand the functionality of the initial implementation of ConservationSpace, refine the system architecture and streamline installation procedures, support implementation at each of the Partner institutions, and promote adoption of the solution by the broader conservation community.

Release 1.5, Installed at Partners (Future). When funded, the vendor will augment the functionality of the system with the Priority 3 workflows, and then adapt the system to each Partner’s enterprise environment, restructuring it if necessary. The vendor will develop additional application functionality and interfaces to make ConservationSpace interoperable with Collection Management, Digital Asset Management, and other enterprise systems currently used at the Partner institutions and with popular CMS and DAM systems used in the broader community. The vendor will also develop utilities to assist in the migration of essential data from legacy sources and advise each Partner in a preliminary data migration effort. In Release 1.5, each Partner institution will receive a fully functional ConservationSpace instance successfully interoperating with their enterprise systems, and ready for pilot use in their conservation work.

Further Releases (Future). When funded, the vendor would work with the Partners to make the system ready for release to the larger conservation community. The vendor would work with the Gallery and the Partners to involve the conservation community in workshops and a process to expand the functional and supportability requirements to address the needs of a broader constituency. The vendor would update the system to address these new requirements and any concerns or opportunities resulting from the pilot use of Release 1.5 at the Partners. The vendor would demonstrate updated release to the Partners and then assist each Partner in updating its installation. The phase would end with a community demonstration of the new release.

Scope of Work The selected developer will work for the National Gallery of Art, in collaboration with the Partners, to develop the Phase 2 (Release 1.0) of the system, and optionally, should the project continue, to develop additional versions and functionality, as defined for later phases.

Specifically, we expect the initial scope of work to include tasking similar to the following outline:

Project Management. Develop and maintain a project plan including but not limited to goals, functional requirements, schedule, budget, staffing, dependencies and risks. Prepare weekly reports to the Gallery technical point of contact and formal monthly contract reports on progress, budgets, issues, etc. Prepare periodic and milestone reviews of work products and deliverables for Partner working groups and the Steering Committee.

Analysis. Analyze the ‘Enterprise Blueprint’ for the system, which will be a systems engineering document giving detailed understanding of the intended operation of the system. The Enterprise Blueprint, will include

· a catalog of all of the activities of the system

· a set of workflows showing how these activities are composed into user threads

· a blueprint for each activity giving some detail as to how the user interacts with the system to perform it, what the system does, what data is used, and requirements or limitations on it

· a catalog of interactions between this system and others Work with the Gallery to gain an understanding of this requirements information, and to clarify it where necessary.

System Design. Working from the definition established in the Enterprise Blueprint, develop a system architecture maximizing off-the-shelf and limiting the use of custom-built components, that is compatible with providing services to users either online or installed within an institution’s enterprise network. Develop a component-level design of the system, including a high-level data model and describing each separately-testable page, class, or service to be included in the system.

Application Design and Development. Create a build plan for the initial, hosted version of the system. The build plan would detail the various activities of the incremental build process, as well as opportunities for Gallery and Partner review of products and progress. For example, the development could proceed in two builds, in which the first build would integrate the core, off-the-shelf tools, into a working version of the system and the second build would develop the essential workflows for conservation, complete any outstanding elements of the core functionality. Each of these builds would include activities of detailed design, implementation, and testing, following the developer’s established methodology. Build 1 would end with a structured online demonstration to the Partners and leave the resulting system available for experimentation and review by Partners during development of the second build.

Follow the approach defined in the Build Plan to develop the first version (Release 1.0) of the system, giving opportunity for Partner review and comment at significant milestones.

Acceptance Testing. The developer would work with the Gallery to prepare a plan and formal procedures for system testing and conduct a full system test, including functionality, integration, performance, and cross-browser testing at a minimum, to be witnessed by the Gallery and selected Partner representatives, to assure that the system meets its stated objectives.

Deployment, Documentation, and Software Packaging. Deploy the system to an agreed upon web-hosting environment. Configure the system as a demonstration system. Prepare system, installation, administration and user documentation. Package the software and make it available in an Open Source software management system.

Support and Maintenance. Provide ongoing technical support and maintenance for bug fixes for an agreed upon period of time.

Full Demonstration Online and Partner Signoff. The developer would conduct a full online demonstration of the system, including all workflows and essential capabilities, to be attended by all of the Partners. Following the full demonstration, the Partners would review the end product and reconfirm their intention to make use of the completed system.

Optional Continuation in Development of Additional Releases. Assuming Partner approval and availability of additional funding, it would be the intent of the project to define similar scopes for the development of one or more additional releases of the system, leading a hosted version that can be tailored for individual institutions and to a version that can be installed locally at a major institution.

Submission Instructions and Conditions The Gallery and the Partners welcome responses that may assist us in preparing our formal solicitation or in identifying qualified developers. After review of submitted materials, the ConservationSpace team may contact respondents to further discuss their qualifications and suggestions.

Responses should be addressed via email, to

Henrietta Brox-Campbell (h-brox@nga.gov)

Responses must be email and received no later than 3:00 PM Eastern Daylight Savings time on Friday, 20 July 2012.

Responses should be no more than 15 pages, as explained in detail in the outline below.

Cover Sheet Please include a cover sheet identifying the organization responding and providing a point of contact, with email and telephone number, to whom questions or clarifications regarding the response should be directed. If this point of contact is not technical, the cover sheet should provide a separate technical point of contact.

Firm Overview (2 pages) The project is looking for an organization with the stability, capacity and depth of skill to undertake the development of the application during the coming year and to support the expansion and improvement of the application in future versions over a period of several years. Please provide an overview of your firm and your development organization, including its core business, location, and size.

You should describe your firm’s background and organizational history, years in business, and range of services provided, as applicable to this Request for Proposal (RFP). Include information bearing on the viability of the company, for example, trends in annual revenue or number of employees. Please also indicate the number of staff currently engaged in development of systems of similar scope and complexity to ConservationSpace.

Please indicate the locations of your offices that could contribute to a project of this nature, including, if known, the location where a team for ConservationSpace would be located.

Please identify your client base (current and over the past few years) for work that is similar in scope, complexity, and application domain to ConservationSpace.

Understanding of Core Technical Issues (6 pages total) At this point in the project, shortly before the release of a formal RFP, the project has identified several areas of significant technical challenge to be considered in selecting a developer. In a short narrative, please respond to the technical concerns outlined in the paragraphs below, demonstrating your team’s understanding and experience with each issue and giving any suggestions you may have for criteria or considerations for the RFP to help assure selection of the best-qualified candidate. If you believe we have overlooked other, equally important technical issues, please bring them to our attention.

Document Management / Case Management Reviewing the need (see, for reference, the preliminary workflows for the system, found at http://conservationspace.org/Build_Phase.html), the core of ConservationSpace seems to be a document management system. It contains extensive requirements for collecting source documents and images, for workflow, for developing documents and reports as end products, for managing versions of those end products, and for collaboration with internal and external colleagues. In addition to these classic document management concerns, there are also requirements for creating and understanding parts or elements of conservation document, fields or text fields, for creating, editing, and searching for them separately. Our market research has identified two primary open-source document management offerings: Nuxeo and Alfresco. In addition, a sister project of ConservationSpace, known as CollectionSpace, is based on Nuxeo, though with significant extensions.

What experience does your firm have with document management technology, particularly open-source document management? From review of the need, can you suggest alternative foundation open-source technologies that we may be overlooking? What criteria would you recommend as most important in selecting a foundation?

Digital Image Management Images of the objects under consideration are essential to any modern conservation project. Most projects make use of several images for references; some projects may be responsible for producing, and reporting on, many, many images, including images taken under differing lighting or different wavelengths. ConservationSpace assumes, therefore, that most conservators will have some separate digital image management capability in which they organize and store their images for reference. In use, they will retrieve images from this store, often highlight or annotate them, and include them in their analyses and reports. Understanding of digital image management is important , then to the technical capability of the ConservationSpace developer.

What experience does your firm have in the development or use of digital image management systems, including the annotation of images and the organization of images for a project? Reviewing the need, what technologies or approaches would you suggest for this important area of ConservationSpace?

Classification, Indexing, and Search Like many built for expert practitioners, ConservationSpace will have to manage a great deal of information, providing ready access to source documents, technical references, images, previous work, and other materials, without interrupting the progress of the work at hand. Users will need to search or browse to find things quickly, and will want to tag or classify their information to aid themselves and others in finding it later. Several controlled vocabularies are current in the field of conservation; various users may choose to adopt one or more of them. Any approach to search or tagging must allow for variation in the terms by which concepts are known and the ability to accommodate multiple languages would be of definite benefit.

What experience does your firm have in the development of information taxonomies, tagging strategies, and search? Can you suggest technology or approaches that the project should consider for search or for managing a controlled vocabulary?

Visual and Flexible User Interfaces Conservation is a very visual occupation; the core activities are the close examination of objects, the development of reports on their condition, and the development of proposals for their preservation. All of these activities entail management of both large volumes of information and various types of images. In addition, conservation involves frequent expert judgment regarding the ordering of activities or the selection of source information. In discussions during the early phases of this project, conservation users often voice a concern that they cannot do their work using a green-screen, database type interface. They need to see images, often multiple images, to select from multiple documents, and they need the ability for flexible configuration of the interface to fit their individual circumstances and work style.

What experience does your firm have in the development of flexible, visual interfaces, particularly for expert users? From review of the need, can you suggest user interface frameworks that ConservationSpace should be considering? What criteria would you say are most critical in selecting user interface technology?

Open Source In order to assure that the initial costs for adoption are moderate and that the costs for maintenance and future adaptation also remain within bounds, ConservationSpace has adopted a strategy to use stable open-source and public domain technology insofar as possible, particularly for basic infrastructure. We expect ConservationSpace to run on an open-source operating system and to give preference to open-source packages or frameworks for the construction of workflow, data management, and search functionality. Perhaps more significantly, ConservationSpace would like to offer 'stand-ins' for external systems that may be missing from an adopting institution’s environment, particularly a collection management system or digital asset management system. It is important also to limit the costs of acquiring these complementary capabilities.

Reliance on open-source technology poses significant challenges, including technical limitations of the available packages, legal limitations of the rights in those packages and any code developed on them, and practical limitations of the availability of support and of qualified developers.

What experience does your firm have with the development of applications that extend or rely significantly on open source technology? What are the principal risks that you see in such an endeavor, particularly one based on technologies of interest to ConservationSpace? What measures should the project take to protect itself from these risks and assure its long-term viability?

Integration with External, Including Legacy, Systems ConservationSpace will need to support interfaces with several types of external systems, but the most important of these are a collection management system (a catalog of objects in a collection) and a digital asset management system for managing images of works of art. Prominent examples of collection management systems are The Museum System (TMS), a commercial product from Gallery Systems, Inc., and CollectionSpace, a sister Mellon-funded project. Asynchronous exchange of data may be sufficient in some cases, but because of the prominence of workflow, there timing or ordering of events may also be necessary. Further, many of these external systems will be legacy proprietary or commercial systems, with limited availability of application programming interfaces. To meet the needs of the broad community, ConservationSpace will eventually need to provide interfaces to several alternatives for each of the external interfaces. Finally, these external systems may be at a different location on a separate network. The strategy for integration with external systems must be open and simple to implement. Ideally, this would use an open and modern mechanism; however, the complexities introduced by the need to accommodate numerous legacy systems is a program challenge.

What experience does your firm have in the development of web services frameworks, particularly where interfaces to numerous, perhaps alternative, legacy systems are required? Can you suggest considerations or criteria that ConservationSpace should include in its request for proposals to assure that our selected developer is able to address this concern?

Configurability Several areas of ConservationSpace require configuration to meet the needs of individual conservators or museums. These configurations could vary in the nuances of workflow—permissions required for treatment of a work of art, the controlled vocabularies to be enforced, or the specific contents expected in various types of reports or analyses. In some of these cases, local configuration could be expected to extend the types data to be managed by the system, or change the appearance of the user interface. Finally, our business is an inherently international one, so the desired local configurations will include provisions for adopting the local language of the users.

What experience does your firm have with the development of configurable systems, particularly document management systems? What key design considerations should ConservationSpace make to provide for local configuration, while maintaining a consistent core code base that minimizes need for local development? What criteria should we consider for inclusion in the request for proposal?

Hosted and Multi-Tenant Systems Although it is being developed initially with the participation of seven major institutions, the community of interest and intended user population is much broader. Conservators work for cultural institutions of all sizes, for commercial enterprises, and in individual practice. The capabilities of ConservationSpace have the potential to serve the needs of all of these constituencies. It is important for the long-term viability of the product that all of them have access to it.

One potential challenge to this access is degree to which information technology interest and expertise varies among the members of this community. While some users, particularly the larger institutions, may prefer and have the necessary expertise, to install and manage the system themselves, many others would welcome anything that reduced the IT barriers to adoption.

The first version of the system to be demonstrated by the project, being available only on the Internet, is a step toward reducing the IT barriers. It offers optimism for a ConservationSpace-as-a-service offering that might attract individual users sometime in the future. Hosting the system would be another way of reducing the IT burden on an adopter who wished a more customized functionality. There are many other formulas that could be considered, and that the project might try out as it matures through development and demonstration.

What experience does your firm have with the development of cloud-based, hosted, or multi-tenanted systems? What pitfalls and advantages do you see in the various approaches that you have used? What considerations would you suggest for the RFP, to assure that we select a developer with the capabilities to support the project through several such phases?

Relevant Experience of the Firm (5 pages) The project is looking for an organization with the experience and expertise to build an attractive application for daily use by conservation professionals in a variety of settings, ranging from major institutions to individual practice.

Please identify project examples that demonstrate your company’s experience in work similar to that described here. Also, please provide one to three case studies highlighting the extent of your familiarity with similar development projects. We are most interested in projects that demonstrate familiarity with the complexities of the ConservationSpace effort, including:

· Use of document management or content management frameworks

· Use of open-source technologies

· Development of highly visual user interfaces

· Experience with conservation, museums, or visual arts clients

Access to examples of the work in these case studies (URLs, screen shots, or documentation) are also welcome.

Appendix—Enterprise Blueprinting

The Partners have been working with Noblis, a Systems Engineering firm, to develop a clear statement of the requirements for the system. Through the three stages of analysis in this ‘Enterprise Blueprinting’ process, we expect to produce several artifacts that will be of value in transferring our understanding of and requirements for the system to the eventual developer.

We entered this process with a great deal of information already in hand, information gleaned from several years of community discussions and several months of Partner collaboration and discussion. This information included:

· Preliminary functional requirements

· Preliminary technical framework information

· 27 Workflows (http://conservationspace.org/Build_Phase.html)

· User stories

· Draft wireframes

· Sample conservation documents from each Partner

· Conservation system examples

In the first stage of the Enterprise Blueprinting process, baseline analysis, we have developed a catalog of the activities necessary to perform the work of ConservationSpace, along with supporting information such as an inventory of user roles, an inventory of technology, and an inventory of information exchanged.

In the second stage, operations analysis, we are analyzing each activity to gain a deeper understanding of its goal, description, and various attributes, and we are linking the activities into ‘Capability Vignettes,’ to show how several of them, taken in sequence, are to be used to create the value needed from the system. We are also working to understand the value of conservation in the larger context of cultural object preservation and study.

In the third stage, systems analysis, we will be considering how the system should work to accomplish these activities, including aspects of the user experience, functional requirements for the system, and business rules that apply. This will give us an ‘Activity Blueprint’ for each activity.

As a result, in the Request for Proposals to be released about September 2012, we expect to include a quite thorough definition of the required system, comprised of the following:

· Activity Catalog

· User Roles Inventory

· Technology Inventory

· Information Exchange Inventory

· Capability Vignettes

· Activity Blueprints image2.jpeg image1.jpeg