Planning for the Architectural Review

This FAQ relates architectural guidance to the ARC process, and provides a bit of process advice. Get help from your case owner for these decisions.

Capable Presenter, Adequate Introduction

Project teams should try to ensure that all cases presented for ARC review are sponsored by an engineer who is both technically involved and can devote sufficient time to presenting the case. The ARC review will require

1. a project summary;
2. an architectural diagram, showing components and interfaces;
3. an interface table, proposing stability classifications and pointing to required specifications;
4. names and installation locations of all project deliverables.

Be familiar with the ARC Policies and Best Practices.

Modifying or Enhancing Existing Projects

Developers of projects that are modifying existing, ARC-approved, projects should review the former ARC cases' opinions, discussion threads and meeting minutes. The team will want to address former architectural concerns (or establish in an Inception review that doing so is unnecessary).

If your project changes a pre-existing project or product, consider whether the changes are "major", "minor", or "micro" (suitable for what kind of release) and why. Major releases are appropriate for unbundled products, but are unforeseen for Solaris; the end-of-feature process is purposefully slow-going and careful. If you're planning incompatibilities between versions, the ARC will want to assure that the upside (to the community and users) is worth the disruption.

Inception Reviews

Use an Inception Review to validate your approach; do so very early in the project's definition. A second Inception Review during development can identify likely issues and determine what information will be needed to achieve Commitment. Do not delay Commitment too long; you can normally fasttrack any architectural changes you find necessary after your Commitment Review.

Perform design reviews of nontrivial design decisions/components. Invite those outside the design group.

Granularity of Review

Consider the granularity of ARC review. A project is typically the smallest amount of change that can stand on its own. If a project is not useful without other projects, they should be reviewed and integrated together. On the other hand, if a project is too much to describe all at once, it is probably too much to review all at once; discuss with your case owner subdividing the review, perhaps into separate projects of a common "program".

Usually, by making a smaller project, the project is more-easily reviewed. But sometimes inter-project interactions become intra-project interactions, below the level of ARC scrutiny, if multiple projects are combined.