Friday June 03, 2005

Sometimes a picture is worth more than a page of blog text. This diagram illustrates my prior posting about basic architectural definitions and their relationships.

Legend (Click on image to see a larger version)
Workspaces	Sun uses Teamware to manage much of its source code. The Teamware term Workspace is used to describe a copy of a source tree that contains its version control history; Teamware can manage the relationships and content flow between workspaces.
I-Teams	Implementation Teams (aka developers)
RE	Release Engineering
Realizations	Instances of a product in specific forms
PLC Phase 3	The first three phases of Sun's Product Life Cycle are "Propose a Concept", "Commit to a Plan" and "Develop a Product". The reference indicates that (duh!) product development happens in the development phase. Yes, there are some people that need to be told the obvious .

Thursday June 02, 2005

Alan Coopersmith writes about making a simple change to Solaris that has a simple architectural impact. This raises the question of how are changes classified?

Obviously, we want to be proactive and intentional about making changes to our products, since the alternative of being suprised by unexpected changes usually means upset customers and broken products.

The development processes we use tries to formalize this intent by asking two basic questions about every proposed change:

• Do we want this particular change?
• Is this the best way to make the change?

The former is primarily a business decision, and the latter, a technical one.

Many times, the want question is obvious - Priority 1 bugs are more "wanted" than Priority 5 ones, competitive pressures may demand certain new features, etc. I won't spend much time discussing this topic, as I want to focus on the technical path.

Architectural Review Committees (ARCs) are made up of senior engineers and other domain experts, and are responsible for the technical review and approval of these changes. The first step in that review process is to determine what kind of review a particular proposal requires:

• The simplest review is None.
  Projects that
  • have had an earlier proposal approved by an ARC,
  • do not introduce new interfaces visible outside their own project, and
  • do not alter any interface visible outside their own project
  usually qualify for self review and automatic approval.

  Most bugfixes qualify for this level of review.

  The documentation provided in the bug report (evaluation, suggested fix...) combined with the usual peer review is deemed to provide sufficient technical oversight.

• Next up is Fast-Track
  A lightweight process for simple cases whose architectural impact is obvious, and that are not likely to be controversial.

  Projects suitable for a fast-track review generally apply "common practice" in a frequently-performed change or addition.

  The fast-track process is primarily handled as email discussions and can take as little as a week's time to complete.

  The intent is that 80% or more of the changes being made will be either self reviewed or fast tracked

• If you don't qualify for any of the above shortcuts, you need a Full ARC Review

  The full ARC review process involves a combination of email, detailed project specifications, and formal meetings. The time required varies considerably, but teams should schedule reviews early - an inception review by mid-prototype stage, with commitment reviews between alpha and beta in order to allow time to incorporate any ARC required changes before integration.

Technorati Tag: OpenSolaris
Technorati Tag: Solaris
( Jun 02 2005, 04:10:57 PM PDT ) Permalink Comments [0]

Wednesday June 01, 2005

Products are made up of one or more components, which are, in turn, made up of one or more elements. Elements and components evolve over time as Projects are initiated to change them.

By watching these changes as they happen, we have a chance to be proactive and manage risk:

• Should we make this change at this time?
• Is this the best way to implement this change?
• What is the impact of making this change on other parts of the system?
• How much will this change cost (risk, time, complexity, resources...)?

Projects

The focus of change management is, of course, a change. We use the word projectto mean "a proposal to make a change to a component". Proposals always reference a specific plan; they may range all the way from the simple (documentation changes and bug fixes) to the complex (new features, refactoring and redesign of major subsystems).

Plans

The formal articulation of a proposal. Plans identify deliverables, schedule, resources, and "completion criteria". If you don't have all of these written down, you don't have a plan, you only have a goal. Plans say "I am going to do this to that by then". Plans can be as simple as an evaluated bug report (evaluation, suggested fix, commit-to-fix release) or as complicated as a business plan with marketing requirements, functional specifications, etc.

Components

A collection of elements that are always delivered together as a self-consistant entity. Components are reusable, sharable things that form the basis for the complicated systems platforms that we deliver. Components are combined to form Releases.

(Think "workspace" or "CVS repository" when you think of components)

Components let us take advantage of independent evolution, decoupling, modularity and reuse - in a very real sense, they are the building blocks that we use to build solutions for our customers.

Changes are made to elements of components. At the beginning, the very first change request is to create a component (i.e., create a new product or feature). However, once a component exists, it spends the rest of its existance being changed. Bugfixes, code restructuring, performance improvements, and the addition of new elements/features all impact the evolution of a component.

Elements

The name we use to describe the thing that remains in a component as a result of making a change. The term is not a formal definition, but it exists so that we don't have to overload the term "project" to mean both the ephimeral process of making a change and the thing that remains as the result of making such a change. Examples include the ls command in the Posix Utilities, the IPV6 or DTrace features in Solaris, the spell checker in OpenOffice, etc)

Products or Distributions

Components do not usually live in isolation - they usually depend on other components, or they do something useful so other components come to depend on them. In that sense, components are usually combined with other components into product releases.

This dependency introduces a risk - the risk that something you depend upon might change in the future and break your component. Or, more likely, you may wish to do something to your component that might break components that depend on yours. This risk management is the focus of Sun's development process.