When Athena is ported to a new platform, Layered Athena should be ported immediately after the first system packs. The new platform should be supplied to ACS, CSS and SIPB, who can use the xlayer GUI to take updates as work progresses on the port. This way, work can begin on courseware, utilities and other locker software early on.
When a vendor introduces a new OS version with binary compatibility, a workstation should be installed with the new version ASAP, and Layered Athena should be used to make it into an Athena workstation. This will help potential problems with the new OS version be identified quickly.
I/S should not attempt to sell the MIT community on the benefits of Layered Athena. We should wait for customers to approach us with needs that Layered Athena could meet, and take appropriate action based on the level of effort involved versus the potential benefit to the MIT community.
We should work with these customers to help them (1) understand the lack of support so that they can avoid too much reliance on the system, and (2) convey this understanding to their users. For example, a faculty member with a special cluster needs to understand that if any coursework depends on Layered Athena, there must be a contingency plan in case it suddenly stops working. We would need to work with such a faculty member to develop a handout for students that would warn them not to rely too heavily on the system continuing to work, and tell them what level of OLC support to expect.
When a ``new model'' for Athena is proposed, it should be described in terms of the three components described in this document: system packs, installation software and locker software. It should be pointed out where the new model is different. When there are differences in the system packs, Figure 1 should be used to illustrate which subsets are different. This will demystify the developer's perspective of the new model.
Of course, the new model should also be described from the user's perspective, i.e. what the workstation looks like when you login. A straightforward change from the developer's perspective may result in a radically different model from the user's perspective, and vice versa.