Hardware and System Selection

When developing a hardware plan, you should consider a number of areas. It may be necessary to delegate this task to a group with enough specific knowledge to research and decide upon the appropriate system requirements for the project’s needs. In addition, the Hardware Team should work in close cooperation with the Software Team to estimate hardware and system infrastructure requirements and to make sure that the RFP contains the necessary questions to assess the repository hardware needs. The scope of the initial implementation will also impact hardware requirements for start up and for scaling (this is discussed in more detail later in the Blueprint)

Some things to consider when selecting a system:

• Network and system availability—System availability must conform to customers’ service hours. A consistent maintenance period is required for systems maintenance and backups. It is important to remember that different types of users will access the system at different times. Instructors may need the resources during the day to compose their lessons, while students are notorious for working late into the night. Generally, maintenance is best scheduled for the early morning hours, when it is least like to be disruptive to users such as Sunday morning between midnight and 6 a.m.


• Network and system capacity—Network and system capacity should be designed to have at least a three year life to any hardware purchase. This ensures that equipment will be remain current and of high quality while in production, and will typically still be viable for non-production purposes after that initial purchase, (such as for use as a test server). Network capacity must be monitored and additional bandwidth on demand should be available.


• Network and system reliability—Network and systems should be designed to ensure reliability for users. Generators and universal power supplies (UPS) should be in place in case of power outages or other unforeseen disasters. It is also vital to have technical systems redundancy, such as fail-over hardware and frequent system back-up.
  
  When any new product is introduced to the system, technical staff should analyze what it would take to make it an application that is available, 24x7. Users will be accessing the repository at all hours, and it is important that it be available on the users demand.
  
  A multi-tiered development environment will also help to ensure this reliability. It should incorporate managed change control across the production and development areas. Ideally, this should include a test server to try out any new software or programming changes. This will allow for experimentation without harming the repository or having to take it offline.
  
  All network and systems should be protected by either a stringent maintenance contract or onsite backup hardware.


• Network and system backup and operational recovery—It is important to have network and system backup and recovery services in place. Should a catastrophic event befall the system, you do not want to lose any of the repository’s content, user accounts, or other information. For The Orange Grove, these services are provided through a contract with SunGard Availability Services. This contract provides for hardware and network replacement in the event of a disaster
  
  It is important to establish a schedule for maintenance and back-up of the repository system. Content must be protected so that the work and time spent collecting, reviewing, and cataloging is not lost. For example, The Orange Grove performs a differential back-up nightly so that all content added during the previous day is saved. A full back-up is conducted weekly, and the system is re-booted weekly as well. The back-up files are stored in a separate location. It may be necessary for the Repository and System Maintenance Team to coordinate with the Technical Infrastructure Team to determine a schedule that allows for the necessary system maintenance, but does not lead to downtime that might affect users.


• Scalability to meet long-term system and network requirements—Scalability must be built into system so that the repository is able to grow and expand and increase the number of users. The system should be designed so that additional capacity can be easily incorporated. Blade or rack servers that can be easily adapted for increased power are recommended. Geographically separated mirror sites may be an option.


• Content driven technology needs—Based on the decisions made by the Content Planning Team, it will be necessary to have the hardware needed to facilitate the types of resources the repository will offer. For example, if streaming audio or video will be available in the repository, a streaming server will be required.

Categorization of projects
One feature of your repository that will largely dictate your hardware needs is the size of the project. You should consider the size of the initial implementation as well as any plans for scaling up the repository in the future.

Both very large scale and small scale repositories tend to be in categories by themselves that make hardware and software choices relatively deterministic. Very large repositories may challenge or exceed the capacities of the existing enterprise infrastructure and technology solutions available from vendors. Their design and implementation will require custom work by senior architects and software engineers, and the choice of hardware and software will be made by a system integrator. Because small scale repositories are likely to be constrained to make use of existing infrastructure and off-the shelf applications, they also have limited, if any choice of technology.

On the other hand, large and medium scale repositories are relatively less constrained by their technical requirements, the enterprise infrastructure, or a pre-existing hardware and software platform. For better or worse, they have a relatively wide-range of choice among several hardware and software products and services that satisfy their requirements.

To further complicate decision-making in implementing them, large and medium scale projects tend also to be in transition from smaller to larger scale. Consequently, decisions about technical infrastructure for these repositories involve not just raw matching of requirements to technology, but trade-offs between current and future requirements, between temporal necessity and architectural model or long range goals, or between growing requirements and limited budget or staff.

To cope with the inevitability of evolving needs and changing resources or constraints, it is important to preserve choice and flexibility by isolating functionality into tiers or service components that can be implemented or switched relatively independently. Reference models, design standards for data structures, interfaces, and communication, and product families are aids to maintaining separation of function.

For example, hosting the user interactions and the search service itself on separate servers will allow the volume of usage and the size of the repository to grow independently. Similarly, isolating application and repository functions from system functions such as switch capacity or bandwidth will allow the latter to grow or change without disrupting the former.

The following lists contrast the characteristics and risks of larger, smaller, and in-between repositories and projects

Larger scale repository projects
Characteristics

• Mission critical function for the parent organization
• Budgeted expense
• 1000’s of multimedia entries that will persist online or in separate storage
• High growth in number and frequent updating or modification of entries
• Several kinds of high-use applications for faculty, students, and librarians (authoring, research, teaching and learning, archiving, etc.)
• 1000’s of simultaneous users with a wide range of competence and experience who expect support
• 24/7 availability and reliable response time
• Integrated policy for securing intellectual property
• Integrated policy for protecting user privacy
• Dedicated staff or contracted services for technical support, disaster recovery, and maintenance
• Supporting materials and training services are provided

Risks

• Broad and costly impact of downtime or loss of data
• Unforeseen impact on the limits of enterprise system capacity or performance
• Non-compliance with organizational, state or federal policy or regulations
• Unforeseen obsolescence due to technology evolution or marketplace activity

Smaller scale repository projects
Characteristics

• Not mission critical for parent organization
• Special budget or outside funding
• Fewer than 1000 entries of primarily one media type that individuals provide and maintain
• Primarily one type of user-facing application (portal, browser-based app, LMS)
• Less than 1000 supported users, most of whom are familiar with the repository entries and how to use the repository
• Slow increase in number of entries and number of users
• Users tolerate interruptions of availability, delayed response times
• Informally enforced security and privacy policy
• Little or no support staff or user documentation
• Ad hoc staff

Risks

• Loss of users due to slow response, inadequate support, etc.
• Ad hoc choices preclude growth or evolution
• Interruptions in or loss of service due to funding gaps, personnel changes, etc.

In-between scale repository projects
Characteristics

• Critical function for parts of parent organization
• Ad hoc funding from regular and special budgets and outside sources
• Accelerating growth in entries, users, and types of users
• Increasing expectations for availability, user support, formal policies, etc.
• Decreasing tolerance for downtime, lack of support materials, slow response to change requests, etc.
• Growing budget and staff requirements
• Increasing exposure to organizational, state, and federal policies and regulations

Risks

• Losses from competition for funding and staff
• Liability from non-compliance with policy or regulations
• Disruptions in service due to changes in governance, operating procedures or technology base
• Administrative or operational inefficiency due to lack of differentiation of functions and roles

Scoping repositories
The dimensions and questions below are designed to categorize repository projects on a continuum from very large to small, personal repositories. A worksheet of questions accompanies this section. The questions are obvious and simple. But detailed answers to these questions will reveal, for repositories that are somewhere between these extremes, the details that are needed for informed decision-making about their technical infrastructure.

Size/Usage
Consider how many users you expect to visit your repository. You may need to come up with two figures, an initial idea and a future projection. As marketing and word-of-mouth and spread, the number of users is likely to increase. You should also consider how many and what type of objects will reside in the repository.

Performance/Availability
It is also vital to consider the needs and expectations of your users. Consider the numbers and types of queries users make, as well as other ways they interact with the system, such as uploading content. What sort of response time might the users expect from the system? How will you monitor if the users needs are being met?

Lifecycle of the entries and the repository service
Begin by establishing a timeline. How soon does the repository need to be up and running? You will need to assess your current funding, resources. There may be existing components or staff members available for the project. Think about how you will seed the repository with your initial content and how you will review that content over time. Also consider how the project will grow and move forward and consider what additional services may be required in the future.

Installation, support and maintenance
A technical support team is critical to ensure that your repository is set up properly and does not suffer from excessive downtime

• Who will install new hardware and/or software? (Vendor, staff, outside source)
• Who will provide on-going support for the technology, for the repository, and for the users? (Training, everyday operation, trouble-shooting)
• Who will provide maintenance and repair? (Vendor, staff members, outside service providers)
• Are written agreements in place for the above?