Thursday July 14, 2005
What is an ARC? 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.
Sun's Architecture Review Committees (ARCs) review and approve technical aspects of software projects, implementing a process to manage technical change in the architecture of our software systems. These architectural reviews:
- assure that a technical description of the project exists,
- assure the developers' plans are technically sound and consistent with current conventions and existing products,
- collect and archive project specifications, and
- improve inter-project coordination: decrease the likelihood that projects conflict with (or duplicate) each other.
The goal of the ARC process is to consistently fulfill our customers' expectations of what a Sun product is, across the product line and over generations of products.
( Jul 14 2005, 03:15:00 PM PDT ) Permalink Comments [0]Reusable components
This is part of a discussion I'm having on the opensolaris-arc mailing list...
One of the recurring problems that we try to manage at Sun is how to effectively reuse components that should be reusable.
Reused components add risk to complex systems, primarily because incompatible changes to a component will break other parts of the system.
The FOSS/distro world many times deals with this situation by resyncing and recompiling whole subsystems every time some component revs in an incompatible way, giving what I call "source level compatability". Think gentoo and autoconf.
The alternative chosen by Sun and others is to provide "binary compatability", even in the face of incompatible change. This requires that we worry a lot more about changes to the interfaces between components:
- Exposing too many implementation details makes it difficult to evolve a component without breaking things that depend on it. We call exposed interfaces "public" and implementation details "private".
- Interfaces have expectations that need to be set and managed. We ask "Can we expect this interface to be stable over releases, or is it more of an experimental thing that will change in the next release?
- As a component evolves, we ask "what interfaces have you changed, and what expectations did you set when you first exposed them?
- We use two taxonomies to help us keep track of all this - an
interface taxonomy that sets expectations of stability and a release
taxonomy that defines the type of release that can contain the
changed interface.
Stability Public Stable, Unstable, Volatile, "not an interface" Private Consolidation Private, Project Private Releases Major, Minor, Micro, Patch There is a relationship between the two:
Incompatible changes to a Stable interface are only allowed to be made in a Major release of the consolidation that contains that interface. Unstable Major or Minor Volatile Major or Minor or Micro NAI Major or Minor or Micro or Patch * Private Major or Minor or Micro or Patch
As long as these components are not reused by anything else in the system, it is easy to "not care" about how they evolve or change. The collection (which we call a "consolidation") is both low-risk and low-maintenance.
As these components start to get reused as building blocks for other consolidations, the potential cost to the system increases. If a component changes in an incompatible way, all the things that depend on it will need to react; if they don't, things may/will break.
The architectural question here really comes directly from kindergarten: "does it play well with others?"
( Jul 14 2005, 02:40:00 PM PDT ) Permalink Comments [0]
This is a personal weblog, I do not speak for my employer.
