Early Adopters

The Campus Testbed Phase of Early Harvest

Frequently Asked Questions

Early Adopters serves three purposes: to help some campuses advance the state of their core middleware infrastructure; to generate additional best practices, particularly in process management, for inclusion in the knowledge base; and to advise the NSF on the issues and challenges in deploying middleware within higher education and research.

Early Adopters will begin with a two-day workshop (a limited amount of travel reimbursement is available) for participants, to be held in early December. The workshop will include extensive discussions of the results of the Early Harvest technical workshop (held in late September), implementation options, campus process discussions, and creation of planning materials.

During the next several months, campuses should move forward on their middleware design and deployment initiatives. To assist them, there will be a number of information-sharing mechanisms to support the campuses in their work. These will include biweekly conference calls, technical briefings, and access to consulting assistance.

In early spring, the participants will be reconvened in a second workshop, to discuss successes, challenges, and next steps, and to gather additional material for the Early Harvest best-practices guide.

The campus must commit to pursuing the design and deployment of core middleware services (coherent identifier management, authentication, and directory services). The campus also agrees to participate in the sharing of technology and process best practices, including involvement in the two workshops, biweekly conference calls, and the aggregation of best practices at periodic intervals.

The campus will get an early opportunity to implement an infrastructure that can be highly leveraged. The campus will be part of a well-supported initiative in this regard, with discussion and consulting opportunities. The leadership and contributions of the participants will be widely acknowledged.

In building enterprise middleware services, there will be considerable requirements for time commitments from senior management within a number of units around campus. There will be the usual project costs of acquiring equipment and software. As is the case with any leadership activity, there is the risk of misdirection, limited economies of scale, and a harder overall effort than for those who follow later.

Internet2 will provide expertise, coordination, and some limited funding support. The expertise will include materials gleaned from the Early Harvest technical workshop, national experts, and ongoing developments in core technologies. Coordination will include operation of the meetings and biweekly conference calls, brokering information needs among participants, and culling materials for the best-practices knowledge base. Funding will include the costs of the workshops and conference calls, and some limited travel reimbursements for participants.

The campus team should include technology developers and technology support people, applications developers (including administrative systems, instructional applications such as web course systems, and basic services such as email and printing services), policy makers (including university legal staff and senior management) and key data providers (including the Registrar and Faculty and Staff Personnel). The campus team is intended to provide overall project oversight, obtain institutional commitments, and involve key constituencies.

A campus needs to submit a brief (2-3 page) application letter to (no longer valid...) by November 12, 1999. The letter should address the following issues:

• Technical resources available to the effort, including central IT staff and campus applications developers.
• Involvement and commitment from the major data owners on campus, including the Registrar, Faculty and Staff Personnel, and other key institutional informational resource providers.
• Involvement and commitment from the major institutional policy makers, including senior management and university legal offices.
• Existing technical infrastructure, including unified campus name space, authentication deployments, and central directories or integrated data warehouses.
• Existing policy infrastructure, including specific guidelines for who has electronic access for major campus IT resources (e.g. network, accounts, email, libraries).

Proposals will be evaluated primarily on 1) the strength of the campus commitment to pursue deployment of a core middleware infrastructure, and 2) its readiness in related technical and policy areas. In addition, selections will be made to maximize the diversity of institutions participating, in order to obtain the broadest possible gathering of best practices in deploying middleware in higher education.

Background material is available from the Internet2 middleware and Early Harvest pages. In particular, a copy of the original NSF proposal is available, as is the Middleware 101 presentation given at the I2 fall member meeting, which describes some of the specific issues that a campus may encounter in deploying core middleware.