\documentstyle[fullpage,12pt]{article}
\title{Athena Layering Opportunity Evaluation}
\author{Mark Rosenstein \& Tim McGovern}
% \date{\verb$Date: 92/11/23 15:12:07 $}

\begin{document}
\maketitle

\section{Abstract}

We propose a new project whose ultimate aim is to develop a Layered
Athena product.  In this OE, we seek approval from ACS, CSS and DCNS
to agree to develop the requirements for such a product.  To that end,
we will need a team with members from each of these departments.  We
include in this OE a brief description of the customer for this
product, as well as the benefits that we expect to get, and the
deliverables we expect to need to produce along the way.  A process
for gathering the requirements is suggested.

\section{Background}

There has been much talk of layering Athena on vendor operating
systems, but up until now we have not really addressed this.  We must
take the opportunity now to do this as an independent project rather
than be forced into it by small decisions made while porting the
environment to new platforms.

\section{Customer}

The customer we are targeting in this project is the person who has
purchased a Unix workstation with their own money, or from a
departmental or sponsored research account. Layered Athena on such a
private workstation means giving the workstation owner the option of
what parts of Athena to install.  There are a spectrum of possible
layerings, from a pure vendor OS to the current Athena model to
copying the entire system pack and some lockers to the local disk.
The workstation owner needs local control over where on this spectrum
his workstation falls and how and when it receives updates.  One
extreme model that may prove popular is where the workstation owner is
not involved at all, but a user without any privileges temporarily
does what is necessary to use Athena services.  Thus the technical
sophistication of the customer might vary quite a bit from site to
site.

\section{Benefits}

We believe there are a number of benefits derived from doing a Layered 
Athena project:
\begin{enumerate}
\item It will help us complete new platform ports easier.  

\item It will allow us to deal better with a source-code free world 
for client platforms (although not necessarily for servers).  

\item It will allow us to expand the use of Athena into departmental 
clusters and labs that do not want to give up their local control.  

\item It will lessen the amount of time our support people spend with 
each special workstation configuration (although this may prompt more 
specials that result in an ultimate increase in support load).  

\item It will also make it easier for us to export Athena services 
outside of MIT, increasing our profile in industry.
\end{enumerate}

\section{Deliverables of the Whole Project}

To achieve these benefits, we must do several discrete things:

First, we need to develop tools that work with a workstation
configuration definition which specifies what software is desired,
what versions of that software, and when it can take updates.  This
configuration (possibly a file on the local workstation, possibly in a
central database for safety) must be under the control of the
workstation owner.  The Layered Athena project should progress in
parallel with Tom Coppeto's project that is aimed at making it easier
for Sun workstation customers to configure for network use.  In the
end, the tools developed in these two projects should dovetails
nicely.

Second, we need to decide how to partition Athena into pieces that can
be chosen and how to encode this partitioning in the release.  We will
need to figure out how this interacts with the current mechanism for
updating the release in the public clusters.

Third, we need to consider how this affects use of licensed software
here and how we can make sure we do not violate our licenses. This
also impacts how people pay for ``Athena system software'' if this
makes it very easy for people to obtain our software.

To simplify the problem somewhat, we should first develop a product for 
a single vendor operating system that we understand well and are not in 
the middle of porting.  We suggest that Ultrix would be a good choice 
for this.  Only after we have a working prototype should we consider 
multiple platforms and folding it into next summer's release, if that is 
called for.

\section{Deliverables From Next Phase--Requirements}

First, we need to gather requirements in two areas:
technical/functional requirements, and service requirements.  Note
that the explicit inclusion of service requirements is a minor change
to the ``orange'' process, and the way we have done some recent
projects.  We have become increasingly aware of the need to be more
explicit about developing at least draft versions of the support and
service plans earlier in the development/product process to ensure
that the products we develop are the ``right'' products.

\section{Next Steps}

Clearly, this project needs to be evaluated from more than just the
DCNS perspective.  To that end, we propose that the Directors of ACS,
CSS and DCNS, in conjunction with their managers, discuss this OE, and
if all agree to move ahead, to assemble a small team to deliver the
deliverables discussed above for the requirements phase.

We propose that the technical/functional requirements gathering
process not be based on starting from scratch, but rather on a set of
requirements that have been bubbling up around Athena and DCNS for a
long time.  We propose that these requirements, as well as the support
requirements, be passed around broadly for comment, including
potential customers.  Before we proceed to design, implementation and
delivery, another decision by the Directors mentioned above would be
required.

In general, we don't expect this project to require a major investment
of resources, although calendar time will be somewhat longer
obviously.  We believe that the proposed technical/functional
requirements could be ready for distribution shortly after this OE is
approved, and a team is assembled.  During the open review/comment
period, which might last for about a month, we would contact key
customers and hold an open forum to get others' response to our
requirements, and revise all of the plans as appropriate.  At this
point, our expectation is that a technical design might take a full
week's effort over a month of real time by Mark and Richard.  We don't
have any estimates at this point about how long the design and
development of the support elements will take, but those estimates
should be developed during the requirements phase.

\end{document}