We identified key success factors that have helped make HP’s firmware cooperative model a success:

• Firmware Architecture: The Owen firmware assets are based on a clean, component-based architecture that exhibits the desired architectural properties of high component coherence, and low component coupling. The architecture is captured in a graphical form which allows each product team to assess quickly the current set of components against the needs of their product. The graphical overview is backup up by excellent component documentation in a standard form. The team can decide which components to use as-is, which need to be changed, and which they need to build from scratch. The clean architecture generally accommodates component extension and addition without difficulty.
  
  
• Development Approach: The Owen firmware development approach is intentionally designed to support the operating model of the cooperative. Central to this is the approach to firmware asset management – the way in which changes to the firmware code are managed. Owen uses a software configuration approach based on “change-sets”. When a project team changes or adds to the set of components – for example, to add a new feature – each individual change is captured as a change set. The key property of change sets is that they can be applied mostly independently. So a project can choose with almost complete freedom which changes it wants to use, and which it doesn’t.
  
  This allows projects to work in a highly decoupled fashion, allowing them to really focus on the requirements of each product. It removes the worry that a change made in one project will have a negative side effect on another project. However, if a great feature or important defect fix has been developed, it’s easy for other projects to include it.
  
  
• Sustaining the Cooperative: A cooperative is only as effective as the people from which it is comprised. The architects of the Owen cooperative sustained its effectiveness by establishing a number of key roles:
  • The Steward is responsible for the smooth running of the cooperative, by liaising with the project teams, embodying the operating principles, convening get-togethers, and so on.
  • The Firmware Architect is responsible for the definition and evolution of the overall firmware component architecture.
  • The Asset Lead is responsible for the firmware code-base itself – with the realization that this is a valuable economic asset.

< Previous page . . 1 2 3 . . Next page >