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.