12 Practices to Consider When Pursuing Systematic Software Reuse

April 15, 2010

Systematic reuse is hard because it isn’t a problem that technology alone can solve. It requires a various practices that have to be executed in a coordinated manner across teams and projects.  Here is a starter list of practices to consider for success with systematic reuse:

  • allocating resources including changes to budgeting practices for funding shared capabilities
  • setting up appropriate incentives for developers, technical leads, and management staff
  • creating a roadmap for increasing organizational agility – reduced time to market, increased flexibility, increased quality – across multiple processes and applications.
  • recognizing failure signs and course-correcting – not only for large initiatives but for individual asset development as well. Don’t forget the need to involve your consumers in addressing delivery and integration challenges.
  • utilizing product line management techniques for identifying, managing, capturing, and realizing variability in business capabilities.
  • explore reuse opportunities not only business functionality but also with IT processes such as bug tracking, problem management, incident management etc.
  • align reuse efforts closely with other initiatives such as service oriented architecture, business process management, master data management etc.
  • Provide training to developers, technical leads, and development managers on what is available, what is being planned, and how the resuable asset inventory is managed/evolved. Make your teams buy-into the effort.
  • Look for reuse opportunities throughout the entire development cycle- not just during implementation! You can reuse requirements, analysis patterns, domain models, business processes, as well as documentation.
  • Aligning reusable assets with business goals/objectives. Remember: the rationale for reuse is to reduce costs and increase revenue for your firm.
  • Communicate reusable assets within your immediate team, then your department, before taking it organization-wide. Without a support and maintenance strategy in place, your reuse efforts cannot be sustained.
  • Address Non Functional Requirements (scalability, reliability, etc.) when creating resuable assets.

Does this resonate with your experience? what is missing in this list?


Software Reuse Quick Tip #23

November 11, 2009

Tip #23 – Design for migration within the product line

Graceful migration within a product line is an often overlooked design trait but is critical for effective systematic reuse. Your products get upgraded or downgraded within a product line. Think of when you switched phone plans from a single user to a family plan or when you signed up for viewing premium content on an online website.  Your design needs to support this in a seamless fashion. The design could support some form of licensing, a policy manager that knows your valid subscriptions and entitlements, and a means to migrate or setup data for a different flavor of a product. You cannot lose customer data and preferences if they upgrade to a different plan or a product in a product line. Reusable assets have to store, access, and update relevant data as a new version is introduced or bug fixes are made.

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to del.icio.us post to facebook


Building Data Services Product Line Using SOA

September 23, 2009

data_svcs_product_lineThe current issue of The Architecture Journal (a Microsoft publication) featured my 5-minute video presentation on building reusable data services as a product line . This is part of the complimentary videos section of the journal’s current issue on Service Oriented Architecture (SOA). [View video]

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


%d bloggers like this: