ACORN Security Refactor Project Charter

I. Problem/Value Statement

Technical Problem Statement

ACORN (A COnservation Records Network) is the Weissman Preservation Center's (WPC) primary application for documenting preservation treatments. It also supports registrarial functions, stores electronic communications, records non-treatment activities, and facilitates reporting. ACORN is convenient for staff, who access the web-based application at the location of their choice.

ACORN was built using Angular on the front end and NodeJS with Express on the back end. Over the years, ACORN’s front end has become increasingly difficult to maintain. Frequent security updates compound the challenge further and have resulted in unresolved vulnerabilities with a high security risk. ACORN’s authentication protocol also needs to be updated to align with the University’s security requirements.

Business Value

Refactoring ACORN’s front-end codebase to shift from Angular to a more easily-maintainable and popular language, like React, will facilitate sustainable maintenance and help prevent the future accrual of security risks by improving the rapidity with which Library Technology Services can respond to security updates. Updating ACORN’s authentication protocol will bring the application in line with current University security requirements.

II. Vision and Approach

The longer-term vision for ACORN is a sustainable, open-source application that supports conservation activities at Harvard and beyond. Work remains to remove references to Harvard-specific systems (e.g., DRS, HOLLIS), although some Harvard-specific dependencies have already been removed, such as Aeon integration. While work to support the move to open source is currently deprioritized within the department, updating the underlying front-end code with an eye to easier maintenance and sustainability supports this vision while also addressing immediate-term security concerns.

The ACORN security refactor aligns with the following Harvard Library multi-year goals and objectives (MYGOs) and HUIT objectives and key results (OKRs): 

• • Harvard Library MYGOs: Evolve our digital infrastructure to meet our directional goals
    • Adopt a sustainable organizational approach to technology lifecycle management and preparing for the future.
    • Simplify and enhance systems that support the discovery and delivery of information resources.

• • HUIT OKRs: Ingrain privacy and security best practices into Harvard's culture and work

III. In Scope/Out of Scope

In Scope

• • Retire ACORN’s use of Angular for its front-end solution
  • Address security vulnerabilities and optimize sustainability for future updates
  • Ensure code is has robust integration and unit test coverage
  • Achieve 100% feature parity with refactored code
  • Update the authentication protocol to use OpenID Connect (OIDC)
  • Update documentation to support the new React front-end codebase

Out of Scope

• • New features

  • Back-end code (NodeJS with Express) changes or enhancements unrelated to the front-end refactor or authentication protocol update

  • Integration of enterprise group and access management

  • Automated QA test suite

IV. Deliverables and Work Products

• Fully-functional ACORN application with a React front-end
• Implementation of OIDC authentication protocol
• Zero security vulnerabilities
• All dependencies addressed

Definition of Done

This project will be successful once we are able to release an updated ACORN application with a React front-end and OIDC-compliant authentication that is free of security vulnerabilities and supported with clear documentation in an easily-findable location.

V. Stakeholders

VI. Team members

VII. Estimated Schedule

Note: Schedule TBD pending vendor estimate and engagement. 

VIII. Assumptions, Risks, and Constraints

Assumptions

• 1. The Executive Sponsor and other stakeholders are empowered to make the decisions required for the project to be a success.

  2. Stakeholders will be available to participate in project activities and to complete tasks as requested in a timely manner.

  3. React is a suitable replacement for Angular.

  4. Existing functionality can be fully replicated in React, achieving 100% feature parity.

  5. ACORN’s back-end requires nominal or no changes to support the new front-end move to React. In the event such changes are required, they’ll have no material impact on the project schedule.

  6. All front-end security vulnerabilities can be resolved by refactoring with React.

  7. ACORN’s codebase allows for the straightforward integration of OIDC without extensive refactoring.

  8. Stakeholders are supportive of the shift from Angular to React and understand both the benefits and potential challenges of this transition.

  9. ​​The vendor is technically proficient to meet project needs. This includes proficiency in React with the ability to readily understand the current Angular codebase of ACORN as well as the OIDC authentication protocol.

  10. The vendor will continue through to project completion with no significant gaps in availability.

  11. The vendor will be available as necessary for check-in meetings.

  12. The documentation deliverable will be sufficient for LTS developers to understand, maintain, and further develop the application.

  13. The project will not require additional resources for development work beyond those identified in section VI. “Team members.”

  14. The budget is sufficient to cover all project costs.

  15. The timeline allows for the completion of all project deliverables.

Risks

Constraints

• 1. Time: There are constraints as to what can be accomplished within the given timeline.
  2. Scope: The project is focused on refactoring the front-end codebase, updating the authentication protocol, and addressing all security vulnerabilities. New features and changes to back-end code outside this focus are out of scope, which could potentially limit application updates or extend development time.
  3. Resources: Since the development work will be done by a vendor, the amount of work that can be done is limited by the vendor’s availability and capacity.
  4. Skillset: The project is dependent on the vendor’s proficiency in React, their understanding of the existing Angular codebase, as well as their familiarity with authentication protocols. If the vendor lacks in these areas, it could impact the project's progress.
  5. Technology: The front-end refactor is constrained by the need to shift from Angular to React. This could limit the design and functionality options for the new front-end.
  6. Quality: The project aims to achieve 100% feature parity with the refactored code. This sets a high standard for the quality of the refactored code and the documentation.
  7. Stakeholders: The project must meet the expectations of multiple stakeholders, each with their own expectations. Balancing their requirements and feedback could influence the project's direction and outcomes.
  8. Budget: The project must adhere to a budget, which could constrain development if there are unforeseen costs associated with the refactoring process or the need for additional resources.

IX. Acceptance

Accepted by Stu Snydman [8/6/2024]

Prepared by Sara Rubinow, with assistance from ChatGPT 4