Systematic Reuse Success Factor #4 – Domain Context

October 10, 2009

There isn’t one right way to build reusable software assets. Your business goals, technical environment, iteration and release plans all contribute to both the timing and nature of design decisions. Refactoring existing code to meet business goals is also context driven. Consider:

  1. What product features typically go together?building blocks
  2. Do certain features vary more than others across products?
  3. Is it possible to vary a product feature at runtime or design-time?

All these questions guide design. For instance, if the goal is to support variability at runtime you could support adding new parameters and changing existing ones without code changes or application restarts. As you work on design, keep your domain relevant variations at the back of mind!

Take an example of a widget shop that needs to market its widgets. The user story is to produce different marketing labels based on widget type. There could be several variations to support – frequency of changes to label information, number of words, language, data formatting, mixture of static and dynamic messages that make up a label etc.

Depending on the complexity of your domain, the features could vary simultaneously or in isolation. Consider some of these variations and their impact on design.

#1 Label contents are only static content – you could use a single LabelGenerator using a file configuration.

#2 Label contents are a mixture of static and dynamic content – LabelGenerator now needs two sub-components – a StaticContentGenerator and a DynamicContentGenerator.

#3 Label contents are a mixture of static and dynamic content. Static content is multi-lingual. – In addition to the content generators you need an internationalization component that can support multiple languages

#4 Label contents are a mixture of static and dynamic content. Static content is multi-lingual. Date and currency formatting varies based on country – All components of #3 plus a DateFormatter and CurrencyFormatter based on locale.

Next time you start a project, understand more about the drivers for change in your problem domain. Your domain and the associated context should drive reuse. The more you understand the drivers the easier it is to decide what and how your software assets need to be reusable.

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

add to Digg it : post to facebook: Stumble It! : :

Systematic Reuse Success Factor #3 – Capture Domain Variations

October 4, 2009

Capturing necessary variations in the domain is extremely important to systematic reuse. Business domains are filled with variations that need to be identified and managed across your codebase. Product line variations are at the heart of effective software reuse. To identify variations in your domain you need go seek subject matter experts as well as end users in your shop. Work with them closely to understand the domain, the aspects that tend to vary often, and how these variations are manifested in user stories. From the customer’s point of view, these variations are a natural way of how their business functions. Invest time to make sure that you not only recognize variations as a whole but also identify the sub-set of variations that really matter.

Given the pragmatic nature of software reuse that is necessary, it is unrealistic to identify all variations in a problem domain. Your iterations will not happen and working software won’t get delivered unless you can include and adapt domain variations as part of your development practices. From a design perspective there are some questions that will help you. Every time you look at a user story you should ask yourself:

  1. What domain entities involved?
  2. Are there entities being encountered for the first time?
  3. Is this story requested in more than one product or application?
  4. What aspect of the domain varies in the story? Some common variations tend to reoccur – the kind of user who uses a feature, number of features being offered, differences in behavior for a feature or a group of features, how features are bundled together based on business criteria, interface metaphors and themes, and reporting/charting capabilities.
  5. Are there a set of user stories or aspects of user stories that appear together often?

Are there additional questions you can ask to capture domain variations?

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

add to Digg it : post to facebook: Stumble It! : :

Signs That Systematic Reuse Efforts Are Succeeding

August 30, 2009

I’ve written previously about systematic reuse being hard, the rationale for taking an agile approach, and the need for pursuing it within the context of business objectives. How do you know you are succeeding and that your efforts are having a positive impact? Here are a few signs to look for:

  • Developers and team leads think about functional capabilities first and implementations next. Teams also start to recognize reusable functionality across applications and projects.
  • Teams have constructive conversations about reusable assets.
  • Development/maintenance costs are distributed across reusable and application specific assets
  • Legacy system capabilities are reused by wrapping native APIs with external/target interfaces
  • Reusable assets are identified and evolved at varying levels of granularity i.e. assets could be simple utilities, components, services, business workflows, etc. and reuse is integrated with other initiatives such as business process management (BPM) and service oriented architecture (SOA).
  • Applications iteratively get transformed from being mostly consisting of application specific code to a mix of application specific and reusable assets. Over time, reusable assets become more sophisticated and start to provide a variety of technical and domain-specific capabilities.
  • Reusable assets are built not for perfection. User stories are continuously aligned with evolving reusable capabilities.
  • Reusable assets are organized in a easily accessible location and designers utilize these assets during design and not only when writing code.

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

add to Digg it : post to facebook: Stumble It! : :

%d bloggers like this: