Justin Erenkrantz wrote: > While this email hints at it, can someone please point us non-Sun > folks at a definition of PSARC and LSARC? What does PS and LS stand > for? What's the dividing line between these ARCs?
[I put this document on the ARC community web site as well: http://www.opensolaris.org/os/community/arc/arc-faq/sun-arc-charter/ -John] From the horses mouth, so to speak, here is the original charter (from 1990) for Sun's Systems Architecture Process. Note that, in the 16 years since this was published we have changed the mix of ARCs to better match the things we were doing. Instead of the "optional software" and "applications" mentioned below, we now have FWARC - firmware LSARC - layered and unbundled software PSARC - platform software SARC - services and customer support SHARC - storage (hardware and software) WSARC - web services, JES -John Date November 30th, 1990 From Eric Schmidt and Wayne Rosing Subject Announcing the Systems Architecture Process Over its eight-year lifetime, Sun has grown rapidly, both in the breadth of its customer base and in the size of its engineering force. Today, it is a serious challenge to develop a diverse set of products that are individually superior yet also are well integrated when installed at the customer site. To help Sun engineers design and implement products that will be successful in the marketplace, we are establishing an Architecture Process. The Architecture Process is a forum for engineers to get advice from Sun's technical leaders and a method to coordinate projects going on in different parts of the company. It is neither a substitute for good engineering nor a bureaucratic set of obstacles put in the path of Sun engineers. All projects in engineering must pass through the Architectural Process before they can released to customers. The Architecture Process has two major aspects: the establishment, maintenance, communication, and enforcement of an overall architecture for Sun products; and the creation, dissemination, and evolution of a compelling technical vision of Sun products several years into the future. The first aspect is the means by which ongoing and new projects are tested against and guided by the architecture. The goal is to consistently fulfill our customers expectations of what a Sun product is, across the product line and over generations of products. The second aspect is to establish the definition of what a "Sun" computer is and will be in the future. We want to capture the imagination of our engineers and focus their efforts on the technology and products that will make Sun be the best computing environment in the industry. The goal is to encourage new projects that will implement and integrate with that vision. To implement the Architecture Process, two organizational structures have been created: the System Architecture Council (SAC) and five Architecture Review Committees (ARCs). The System Architecture Council is a group composed of technical leaders from across the engineering organization. The ARCs operate as subcommittees of SAC, containing some SAC members and some non- SAC members. Both SAC and the ARCs are composed of senior engineers, and focus on technical issues. Most project review and architectural review occurs in the ARC- teams. The ARCs are organized by areas so that most projects can seek review by a single ARC. The five areas are: platform hardware (systems, CPUs, buses) optional hardware (I/O devices, graphics processors) platform software (operating system, base networking, window system) optional software (compilers, CASE, pervasive system or network services) applications (end-user applications, user interface) The definitions of the areas are intentionally approximate so that workload can be balanced across the ARCs. To provide broad architectural review, each ARC will have a spectrum of experts, rather than focusing on a particular area of expertise. SAC will organize the evolution of existing A-teams into the new structure over the next few months to assure continuity of ongoing reviews. [A-Teams = Architecture Teams - John] ARCs are involved in projects at three stages. Before a project can be committed, it must be reviewed for architectural issues to be considered by the implementors. When a design is complete, a more detailed review of the spec is done for architectural conformance. Finally, before a product can ship, it is given one last check for architectural integrity. A project that does not change existing interfaces or define new ones can expect quick approval. A project that breaks new ground is likely to involve closer scrutiny. SAC manages the ARCs, deals with appeals of ARC decisions, and considers issues of company-wide architectural implications. It is also responsible for developing the overall vision of Sun products. SAC members who are also ARC members provide the communication between SAC and ARCs. SAC and the ARCs work together to organize and maintain the definitions of the architectures, standards, and interfaces that Sun products must conform to. It will establish an online library of documents describing approved architectures, including Sun interfaces and Sun usage of external standards, and a process for adding to and amending them. The results of SAC decisions will also be accessible online. All Sun engineers will be made aware of this library, and may use it as a source of information in designing products. These documents will also be the basis for architectural review. [This refers to the case archives - see http://www.opensolaris.org/os/community/arc/caselog/ - John] The Architecture Process is being created to meet a need, often expressed by Sun engineers, for more coordination among different groups. If we think of it as simply a set of bureaucratic hurdles or a sequence of legalistic maneuvers, then it will be a waste of time for everyone. The value of the process comes from the excellence and expertise of the people who participate in it and the communication it encourages. We intend it to help empower and increase the leverage of every Sun engineer. --Eric Schmidt and Wayne Rosing
