Sun's System Architecture Council and the Architecture Process: Invitation to Partcipate

[nils <n p sun com>]

Hi there,

The GNOME team in Ireland will taking the various components of GNOME
2.0 through Sun's architectural review process. A number of us thought 
it would beneficial to the community as a whole if we shared this 
information:

1) because some guys from Ireland might be asking you for help in
   answering some of the questions required for the review process.
2) because it may help you understand some of the architectural
   constraints that an engineering team at Sun has when it is
   developing/delivering a product.

There are normally two steps to the review process:

1) inception review - normally should occur around the prototype stage
2) commitment review - normally should occur when the project still
   has time to fix any architectural problems that may arise, before 
   shipping.
 
For each review a project completes a questionnaire (for some
reason know as 20 questions - even though there are a lot more known 
questions that 20 :-)). The review looks at the interconnections between 
components of a project, as well as the interfaces used and exposed by  
it, with the goal of categorizing their relative stability, evolutionary 
constraints, and managing risk over time. A project is also encouraged 
to supply a functional spec, but sometimes man pages suffice. A copy of
the questionnaire can be found at: 

http://developer.gnome.org/dotplan/archreview/20questions.html

Any issues that arise at inception review are tracked through to a 
commitment review. Assuming all the issues are resolved positively, this
usually results in an approval vote by the review committee 
(The vast majority of cases are approved). The committee then writes an 
opinion which may contain required, recommended, and optional advice. 
A project cannot ship unless required changes are complied with. Now 
there's an appeals process as well - but I won't go into that here 
because it's a bit too Sun specific.

Now the interesting thing with GNOME is that its one of the first large
open source projects that will be going through this process. Sun's System 
Architecture Committee is not sure how well Sun's process will adapt to 
open source projects. So, that's why we'd like your feedback. Perhaps the 
best way is to participate in the actual reviews. Anyway, let me know if 
you'd like me to post Sun's GNOME review schedule to this alias, alternatively 
we could contact component 'owners' individually.

Nils 
 
GNOME/Solaris HCI and Architectural Review Committee member



******

 
<Below is a more formal and idealistic description of the Architecture
Process>

The Systems Architecture Council and the Architecture Process

The Systems Architecture Council (SAC) and its subcommittees, the
Architecture Review Committees (ARCs) are responsible for the
architecture process at Sun. The "Systems Architecture" effort at Sun
is a process that establishes the basis for multiple engineering
projects to be developed in parallel, and then to integrate with each
other and the existing system, either at Sun or in the customer's
hands.

In addition, architecture establishes a "model" of the system - a
record of the components contained in the system and the interfaces
between these components. This is very important, as many of the
interfaces offered by the system represent commitments that we
have made to our customers which we are obligated to honor by
preserving these interfaces.

In general, Systems Architecture establishes and preserves the basic
principles of design evidenced in Sun products.

The Architecture Process

The architecture process has two parts: a "pro-active" part that
attempts to provide guidance to the company by projecting future
trends in technology to identify business and technical opportunities;
and a "re-active" part that examines each change to the product
and determines its position and suitability relative to the whole
collection of Sun products.

This latter part of the process is administered by Architecture Review
Committees (ARCs). There are a number of ARCs, each of
which are equivalent in the review function they perform. There is
more than one ARC in order to distribute the workload. ARCs range
in size from 9 to 12 members, drawn from the senior technical ranks of
the company. Each member is a current individual contributor
-- ARC participation is not a "job description." The method for
dividing workload (i.e. assigning a given project's review to a particular
ARC) is essentially "static": Each ARC is most closely associated with
a pre-decided "category" of product changes.

It is important to note that ARCs are not responsible for designing
projects. They are instead responsible for discerning our actual
product architecture through an examination of the changes Sun
attempts to make. This keeps the activity relevant rather than merely
academic, and provides a way to capture our experience through
decisions and from this empirically describe our architecture.
Collectively, ARCs "write the architecture book" as a consequence of
their review activities.