FAQ

Architectural Review - Frequently Asked Questions

In the process of chartering a new ARC, several managers and engineers who were unfamiliar with the ARC process asked questions about the scope of ARC reviews and grounds on which an ARC might require changes to a project, or even reject it. There is considerable documentation on what kinds of information the ARC will be looking for (See the ARC Best Practices), but this does not do much to set expectations (for either reviewers or reviewees) about what types of problems might justify formal objections (TCRs or rejections) to the case.

This part of the web site is an attempt to distill some guidelines from past experience. It is probably neither comprehensive nor unambiguous, but at least it is a starting point.

Goals and non-Goals for Architectural Reviews

 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).

See the goals page for more details

Scope of Inquiry in Architectural Reviews

 When an ARC reviews a project, they are seeking to understand the architectural components, and their interactions with one-another and with the rest of the system. Armed with this understanding, the ARC members will apply their experience to considering the potential ramifications of the proposed architecture, and suggest changes to avoid likely problems. The ``scope of inquiry'' in an architectural review is, therefore:

 ``anything that the ARC members might need to know in order to understand the product architecture and its implications.''

 The greatest emphasis is usually on the project's interfaces - since these define the rules according to which independently deliverable components will interact. By interfaces we do not merely refer to "APIs and GUIs", but to protocols, schemas, data formats, packaging, administration, etc. In addition to examining the adequacy of the interfaces for common operations, they are also examined for interoperability, upgradability, supportability, scalability, security implications, performance implications, etc.

Architectural Review is not intended to be a design or code review. It is assumed that the project teams will carry these out as part of the standard development process. In some cases, however, it may be necessary to ask questions about the proposed implementation in order to better understand how the interfaces can and cannot be used. Similarly, it may be necessary to follow the system through common operational scenarios in order to understand all of the operational aspects of a proposed project. If, in the course of these investigations, design problems are encountered, it is appropriate for the committee to comment on these.

 Architectural review is not intended to be a review of the product requirements. It is assumed that the product management organizations understand their customers and have done due diligence in defining the product requirements. To understand the installation and management aspects of a product, however, it may be necessary for the committee to explore questions about who the intended customers are and how they will obtain and use the product. If, in the course of these investigations, the committee discovers potential problems with the stated product requirements, it is appropriate for the committee to comment on these.

 As such, the scope of reasonable inquiry during the course of an ARC review is very broad. The limitations are not so much on the kinds of question that the ARC might ask, as they are on the types of suggestions that the ARC might make as a result of their inquiries.

FAQ Document Links

• How do I publish/request an existing Sun ARC Case?
• Request Tracking Table
• When should developers interact with the ARC?
• What sort of changes need ARC approval?
• What is an ARC Review?
• Planning for the Architectural Review
• How to succeed with an Architectural review
• General Principles for Requiring Changes to Projects
• Announcing the Systems Architecture Process
• Use of the OpenSolaris aliases
• ARC Fast-Track Sponsor Duties
• ARC Fasttrack Handbook