Evolve a reusable asset iteratively

When you recognize the need for a reusable software asset it is key to map out a realization strategy. If you approach asset realization big bang you could:drowning_your_savings

  • end up creating a software asset that is irrelevant to your project’s immediate needs
  • add significant schedule risk due due to increased design, development, and testing time

Either way, you will spend a ton of precious $ drowning your savings.

Instead mitigate these risks by evolving the reusable asset over multiple iterations. Take the example of a reusable assets that sends notifications to your users. Let us name the asset Business Notifier. Instead of trying to build the 100 bells and whistles that this asset could have we come up with a simple plan to evolve it over several iterations. building_your_savings

Iteration #1 – notification via email for predefined business events
Iteration #2 – allow user to choose notifications out of the business events
Iteration #3 –  let users define custom business rules to generate business events
Iteration #4 – send notifications on a web console or instant messaging applications
Iteration #5 – allow users to include their friends when receiving notifications.
Iteration #6 – integrate notifications with workflow for review by a support person

Obviously this is just an example and the features you put in an iteration are based on business requirements, priority, ease of implementation, and project deadlines. You could for example reduce investment in an asset if it is no longer a priority or vice-versa.

The takeaway is no matter what you want to build as a reusable asset plan its evolution over multiple iterations. You will reduce risks, stay flexible to your business requirements and needs, and build only assets that you want to invest in.

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

Advertisements

One Response to Evolve a reusable asset iteratively

  1. […] Reusable asset design – pursue iteration, not perfection You want to make sure that you don’t spend an enormous time trying to build the perfect reusable asset. Be it a component, library, or service. Regardless of what you are trying to do accept that you won’t be perfect from the get-go. Instead design for reuse iteratively. In earlier posts I blogged about delaying commitment and gave an example of an iterative way to build a reusable asset. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: